Webhooks: send record changes to any URL

A webhook is your database telling something else what happened, the moment it happens. A record changes in Tabla; Tabla sends an HTTP POST with the full story — the record before, the record after, which fields changed — to a URL you chose. The thing at that URL, an n8n workflow, a Make scenario, or twenty lines of your own code, does whatever comes next. Nothing polls, and nothing is five minutes late.

Every database has a Webhooks tab, next to Data at the top of a laptop or tablet screen. The list answers three questions per webhook in one scan: what fires it, where it goes, and whether it's healthy.

Configuration is a sentence

A webhook's setup reads the way you'd say it. The list shows each one as a one-line summary — When a record is created in Orders → hook.eu2.make.com — and the webhook's own page is that same sentence as a form: When [trigger] in [table], then Send to with the URL. There is no Save button; every control commits itself as you change it, like the rest of Tabla.

The four triggers

One webhook has exactly one trigger, picked from the When menu:

• a record is created — fires once per new record.
• a record is updated — fires on every edit. Optionally narrow it to Watched fields, so only changes to the fields you name count.
• a record starts matching — the stateful one. You write conditions, and the webhook fires at the moment a record goes from not matching to matching — an order's Status arriving at Out for delivery, once, rather than on every later edit while it sits there. Conditions that name a moment ("today", "now") are also checked on a clock, so a record can start matching because time passed, with nothing written.
• a record is deleted — fires with the record's final state, so the data isn't gone from your automation's point of view.

All four take conditions in the same grammar as filters, so When a record is updated in Orders can become …and Status is Delivered with the same rows you'd build in the Filter panel.

One table, or the whole database

The in menu offers every table, plus any table — one webhook watching the entire database. Two things need a specific table: conditions and watched fields, since both name fields, and only a table has a field list. (a record starts matching always needs a table, for the same reason.)

Signed, logged, retried, replayable

The promise behind every delivery, each with its own guide:

• Signed. Every request carries an X-Tabla-Signature header — an HMAC-SHA256 over the timestamp and the exact body, keyed with a secret only you and Tabla hold. Verify it and no one can feed your endpoint forged events.
• Logged. Every attempt lands in the delivery ledger on the webhook's page: the exact payload sent, the response that came back, the HTTP status, the duration. Thirty days of history, always keeping at least the last 200.
• Retried. A failed delivery is retried after 10 seconds, 1 minute, and 5 minutes — four attempts in all. After 20 straight failures the webhook pauses itself instead of hammering a dead endpoint, and says so with a chip in the list and a dot on the Webhooks tab.
• Replayable. Any delivery in the ledger can be sent again with one click — same payload, fresh signature — so an outage on your side doesn't mean the events are gone.

What arrives

One JSON envelope per change: the event name (record.created, record.updated, record.matches, record.deleted), the database, table and record ids, changed_field_ids, and full before and after snapshots of the record. Your receiver never has to call back to ask what actually changed. The field-by-field reference, with a real captured payload per trigger, is webhook payloads.

Before anything fires, the Example payload disclosure on the webhook's page shows the exact shape your table will send — built from your real field names — and Send a test delivers a sample to your URL on the spot.

The honest details

• Bulk writes don't fire webhooks. A change touching 50 or more records at once — a big import, a mass paste — sends nothing, on purpose. Fifty webhook calls for one paste is a flood, not a signal. Ordinary edits and single-record API writes are always under the line.
• Public URLs only. The destination must be reachable on the public internet; local and private-network addresses are refused when you save.
• Who can do what. Editors and owners create, edit, pause, and delete webhooks and can send tests and replays. Viewers can read the list and the ledger, but never the signing secret.
• Paused means paused. While a webhook is off or auto-paused, events that happen are not queued up for later — resuming starts from now.
• A button field can also send one delivery to a webhook's URL per press — a human trigger riding the same signing, ledger, and retries.

Webhooks are on every plan, like everything else. If you're deciding between webhooks and polling the API, or wiring up Make or n8n for the first time, the concept piece on database webhooks is the place to start; your first webhook is the ten-minute version with a real endpoint.