Tabla and n8n: a webhook into a workflow

n8n's job is the then: a record changes in Tabla, and n8n sends the email, posts to the channel, files the invoice. The wiring is one webhook on the Tabla side and two nodes on the n8n side — a Webhook trigger and, when the flow writes back, an HTTP Request node.

This guide names nodes and fields rather than showing n8n's screens — their interface moves; the shape of the flow doesn't. The running example: when an order's Status arrives at Out for delivery, tell the courier system, then mark the order assigned.

Get a URL from n8n

1. Create a workflow and add a Webhook node as its trigger.
2. Set its HTTP Method to POST. Leave the response setting alone — the node acknowledges the request without waiting for the rest of the flow, which is exactly what a webhook sender wants.
3. The node offers two URLs: a test URL, live only while you're listening in the editor, and a production URL, live once the workflow is active. Copy the test URL for now.

The URL must be reachable from the public internet. n8n's hosted service is; a self-hosted n8n on a private network isn't, and Tabla will refuse the address when you save.

Point a Tabla webhook at it

In the database's Webhooks tab, Add webhook:

When a record starts matching in Orders — with the condition Status is Out for delivery — Send to the n8n URL.

Starts matching fires once per arrival into the state, not on every later edit — the semantics. If every edit is what you want, use a record is updated with watched fields instead.

Teach n8n the shape

Set the Webhook node listening (n8n's editor has an execute-and-wait state for exactly this), then click Send a test on the Tabla side. A sample delivery arrives, built with your table's real field names — and n8n now shows the payload's structure, ready to map from.

Then send one real event — flip an order to Out for delivery — and pin that execution instead. Real values beat sample values while you build.

Read the record in the flow

The delivery is the POST body: event, record_id, full before and after snapshots, changed_field_ids — the payload reference. The Webhook node hands the request to the next node with the JSON under its body property, so downstream expressions drill in along the lines of:

{{ $json.body.after.fields["Customer email"] }}
{{ $json.body.after.fields.Status }}
{{ $json.body.record_id }}

The exact root ($json.body here) can differ with the node's settings — open the node's output panel once and read the real structure rather than trusting any guide, this one included.

Two habits that keep a flow alive:

• Bind to field ids, not names, for anything long-lived. Set the Tabla webhook's Cells keyed by to Field id and a colleague renaming Customer email can't break your mapping; the field_names map still rides along for reading.
• Dedupe on delivery_id. Delivery is at-least-once; an n8n outage at the wrong moment can mean the same delivery twice. Branch on a seen delivery_id (a Code node with workflow static data, or your own store) before anything that must not run twice.

Write back through the API

To act on Tabla — mark the order, stamp a time — add an HTTP Request node:

• Method: PATCH
• URL: https://tabladb.com/api/tables/tbl_sf6ir2p5y3uc/records
• Header: Authorization: Bearer key_xxxx.your-secret
• Body (JSON):

{
  "records": [
    {
      "id": "{{ $json.body.record_id }}",
      "fields": { "Assigned to": "omar@sakkaraplants.com" }
    }
  ]
}

That's the ordinary records API — the webhook carried the record_id, so no lookup round trip. Keep the API key in an n8n credential, not pasted into the node.

One loop to not build: this very node's PATCH fires a record is updated webhooks on the table. A webhook that triggers a flow that edits the record that fires the webhook is an infinite loop with your name on it. Watched fields and conditions are the guard — trigger on Status, write to Assigned to, and the circle can't close.

Go live

Activate the workflow, then swap the Tabla webhook's URL from the test URL to the production URL — they differ, and a webhook left pointed at the test URL delivers only while the editor is listening; the rest of the time those deliveries fail (and show as failures in the ledger, which is how you'd notice).

If the endpoint does anything that matters, verify the signature; for the architecture of the whole pattern — payloads, retries, idempotency — the concept piece is database webhooks with Make and n8n.