Tabla and Make: the app, and the nine modules

Tabla is an app inside Make, listed and verified. Add a module, search for Tabla, connect it once with an API key, and the database is there — searchable, writable, and able to start a scenario the moment a record changes.

This used to be a wiring job: a Custom webhook module to receive, an HTTP module to write back, and your API key typed onto every single call. That still works, and there's a section on when you'd want it. It is no longer the way in.

Module names only, no screenshots — Make redraws its interface often enough that pictures of it lie within a year.

Connect it once

Mint a key in Tabla from the account menu, top right → API keys. It looks like key_xxxxxxxxxxxx.your-secret and is shown once, so copy it then.

In Make, drop in any Tabla module, choose Add on the Connection field, and paste the key. Every module and every dropdown uses that one connection afterwards. A key can be made read-only or scoped to certain databases — a scenario that only reads should hold a key that can only read.

The nine modules

Module	What it does
Watch records	Instant trigger — fires when a record changes
Search records	Finds records, with filters, sort and paging handled
Get a record	Reads one record by its id
Create a record	One real input per column
Update a record	Changes a record by id; blank fields are left alone
Upsert a record	Updates a match, or creates one if there is none
Delete a record	Moves a record to the trash
Upload an attachment	Mapped bytes or a public URL, into an attachment cell
Make an API call	Any endpoint, for anything the eight above don't cover

Start a scenario when a record changes

Watch records is the first module in the scenario. Pick the database and table, choose what counts as a change — created, updated, starts matching a condition, or deleted — and Make registers the webhook on Tabla's side for you. There is no address to copy, no listening state, and no "determine data structure" step.

Each delivery carries the whole record, before and after, so the scenario never goes back to ask what changed:

• After expands straight to the fields. Before is empty on a created record and filled on an updated one.
• Changed field ids names what actually moved.
• Field names maps each field id back to its human column name.
• Delivery ID is the dedup key. Delivery is at-least-once, so the same delivery can arrive twice around a timeout — remember the ones you've processed.
• Test delivery is true for the test you fire from Tabla's webhook page. Filter those out before anything real happens.

A bulk write of fifty or more records fires no deliveries — that's a bulk edit, not fifty events.

Turning the trigger off unsubscribes it; nothing keeps arriving at a scenario you switched off.

Read and write

Search records builds its filter from dropdowns — pick the field, pick the operator, pick the value. It is not a formula you type, and it stores field ids underneath, so renaming a column later doesn't quietly break the scenario. Paging is handled inside the module; Maximum number of records is simply where it stops.

Create, Update and Upsert give you one real input per column rather than one JSON blob — a date picker on a date, a dropdown on a select, a checkbox on a checkbox. Update leaves blank fields alone rather than clearing them. Upsert matches on the fields you nominate, and on a match attachment cells append rather than replace.

A date-only field stays a calendar day. Write 2026-09-01 and it reads back 2026-09-01, rather than becoming a timestamp that lands on the day before in another time zone.

Make an API call

For anything the other eight don't cover. Give it a path — /databases, /tables/tbl_xxxxxxxxxxxx/records — with the method, query string, headers and body. Authorization is already handled by the connection; you don't add it. The full reference is at /docs/api.

When you'd still wire a webhook by hand

The app is the short way into Make specifically. A raw Tabla webhook is still the right tool when:

• you're on n8n, Zapier, or your own code — anything with a URL;
• you want the raw signed payload, and to verify the signature yourself;
• you want the delivery ledger and Replay as your operational surface.

The mechanics of that path — pointing a webhook at a Custom webhook module, teaching it the shape with Send a test, writing back with an HTTP module — are in database webhooks with Make and n8n, along with conditions and the payload reference.

One habit worth keeping either way: mind the loop. A scenario that writes back to the same table can re-trigger itself. Trigger on one field, write to another, and use watched fields so the circle can't close.