n8n, Zapier and no-code tools

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

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:

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": "[email protected]", "source": "webinar"}'

Read rows with filters in the query string:

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:

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:

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; the jobs show up on the project's Cron tab.

Related

• Database webhooks and HTTP requests with pg_net
• Debugging database webhooks and pg_net
• The Data API (REST)
• Keeping keys safe