# n8n, Zapier and no-code tools

> Connect n8n, Zapier, Make and other no-code tools to a SupaHost project with its URL and API key, push database changes to them with pg_net, and know which connector types won't work.

Source: https://supahost.app/docs/integrations/no-code · Updated 2026-11-11

Automation tools can read and write your SupaHost project the same way your app does: over HTTPS with the project URL and an API key. They can also be told about changes as they happen, by having the database call a webhook URL. What they can't do is open a direct Postgres connection, because SupaHost doesn't expose Postgres to the internet.

## Which connectors work

| Connector type | Works? | Notes |
|---|---|---|
| "Supabase" nodes or apps that ask for a project URL and API key | Yes | Use your project URL and the `service_role` key (or `anon`, if RLS policies allow what the workflow does). |
| HTTP request steps calling the Data API, Edge Functions or Storage | Yes | Send the `apikey` header. |
| Incoming webhooks triggered by your database | Yes | With `pg_net` or a database webhook, below. |
| "Postgres" nodes that ask for host, port, user and password | No | Needs a public Postgres endpoint. |
| Connectors that "Sign in with Supabase" to pick a project | No | They use Supabase's Management API, which SupaHost doesn't offer. |

## Credentials

From your project's **Connect** tab (subtab **App**):

- **Host / Project URL:** `https://app-one.acme.supahost.space`
- **API key:** the `service_role` key (click **Reveal**, owner only)

The `service_role` key bypasses Row Level Security and can do anything in the project, so it lives only in the tool's credential store. If a workflow only needs to read public data, give it the `anon` key instead and let your policies limit it.

### n8n

Create a **Supabase** credential with **Host** set to your project URL and **Service Role Secret** set to the `service_role` key. The Supabase node can then get, create, update and delete rows in your tables.

### Zapier and Make

Both have Supabase apps that connect with a project URL and API key. If one asks you to sign in to a Supabase account instead, use their generic HTTP or webhook modules with the requests below.

## Calling the API directly

Any tool with an HTTP step can use the Data API. Insert a row:

```bash
curl -X POST "https://app-one.acme.supahost.space/rest/v1/leads" \
  -H "apikey: $SUPABASE_SERVICE_ROLE_KEY" \
  -H "Content-Type: application/json" \
  -H "Prefer: return=representation" \
  -d '{"email": "dana@example.com", "source": "webinar"}'
```

Read rows with filters in the query string:

```bash
curl "https://app-one.acme.supahost.space/rest/v1/leads?select=email,source&source=eq.webinar&order=created_at.desc&limit=50" \
  -H "apikey: $SUPABASE_SERVICE_ROLE_KEY"
```

When only `apikey` is sent, SupaHost copies it into the `Authorization` header for you, so one header is enough. Responses are capped at 1000 rows; page through larger sets with `limit` and `offset`.

Call an Edge Function the same way, at `https://app-one.acme.supahost.space/functions/v1/<name>`, with `Authorization: Bearer <key>` if the function has **Require JWT** on.

## Sending database changes to a workflow

To start a workflow when something happens in the database, give the tool a webhook trigger (n8n's Webhook node, a Zapier "Catch Hook", a Make custom webhook) and have Postgres call it. `pg_net` is installed in every SupaHost project:

```sql
create or replace function public.notify_new_lead()
returns trigger
language plpgsql
security definer
set search_path = ''
as $$
begin
  perform net.http_post(
    url := 'https://n8n.example.com/webhook/new-lead',
    body := jsonb_build_object(
      'id', new.id,
      'email', new.email,
      'source', new.source
    ),
    headers := '{"Content-Type": "application/json"}'::jsonb
  );
  return new;
end;
$$;

create trigger leads_to_n8n
  after insert on public.leads
  for each row execute function public.notify_new_lead();
```

The request is sent in the background after the insert commits, so a slow or offline workflow tool doesn't block writes. Responses are kept for a short time in `net._http_response`, which helps when something isn't arriving:

```sql
select id, status_code, content, created
from net._http_response
order by created desc
limit 10;
```

Use a long, random path in the webhook URL, or have the tool check a header with a shared secret, so nobody else can post fake events to it.

Studio's Database Webhooks page (click **Studio** in the project header) creates the same kind of trigger through a form, using the `supabase_functions` schema that every SupaHost project has.

## Running workflows on a schedule

If the tool only needs to pull data now and then, its own scheduler works. If the job is pure database work (closing stale leads, refreshing a summary table), it's simpler to run it inside Postgres with [pg_cron](/docs/cron-queues/cron); the jobs show up on the project's **Cron** tab.

## Related

- [Database webhooks and HTTP requests with pg_net](/docs/database/webhooks)
- [Debugging database webhooks and pg_net](/kb/webhook-debugging)
- [The Data API (REST)](/docs/api/overview)
- [Keeping keys safe](/docs/security/api-key-safety)