Your database, wired to 7,000 apps

The uncomfortable thing about owning your data is that everything else lives somewhere else. Your forms are in one tool, your payments in another, your support queue in a third, and the database you actually own sits politely to one side.

Zapier is how that stops being true, and SchemaStack has a published integration for it.

What it does

Triggers — your data starting a workflow:

• New Row — a row was added
• Updated Row — a row changed
• Table List — not user-facing; it fills the table dropdowns so you pick from your real tables rather than typing a name

Actions — a workflow writing to your data:

• Create Row — a POST
• Update Row — a PATCH, so only the fields you map are touched and everything else keeps its value

Search — Find Row, looking up a row by any column, with the column list populated from your actual schema.

Connecting it

A workspace API key, your organisation slug and your workspace slug. The key is scoped to one workspace and revocable on its own, so a Zap that goes wrong is a Zap you can cut off without touching anything else.

Worth being clear about where the data sits: nothing is copied into Zapier, and nothing is copied into us. Every trigger reads and every action writes the PostgreSQL or MySQL database you already own. Zapier is a courier.

Two details that took work

De-duplication needs an id, and yours might not be called that. Zapier decides whether it has seen a row before by looking at a field literally named id. Plenty of tables don't have one — a customer_id primary key, or a composite key across two columns. So the integration detects the real primary key and presents it as id, joining the parts with | for composite keys. Without that, a table with a sensibly-named key would either fire repeatedly for the same row or not fire at all.

Finding the newest row depends on what the key is. An auto-increment integer key means the highest number is the newest, so it sorts by the key. A UUID key means nothing of the sort — UUIDs aren't sequential — so it sorts by a timestamp column instead. Getting this wrong doesn't produce an error; it produces a trigger that quietly returns the wrong rows, which is worse.

That last sentence turned out to be a prophecy about this integration itself. Until version 1.5.2 the triggers wrote the sort as field.desc where the API's syntax is field,desc — a request the API silently ignored, handing back rows in primary-key ascending order under a 200. Every de-duplication and windowing decision described above was running on the wrong 25 rows the whole time, and nothing anywhere said so. What finally surfaced it was the API learning to refuse: on 2026-08-27 an unknown sort field became a 400 instead of a shrug, the very next poll got refused, and the fix shipped the same evening. The trigger genuinely polls newest-first now — for the first time.

What it doesn't do (yet)

• Updated Row requires an updated_at column set to change on update. Without one there is nothing to sort by and nothing to compare, so the trigger has nothing to work with. This is stated in the trigger's own description, not buried here.
• Updated Row also fires for freshly inserted rows unless they're filtered out, which the integration does by discarding rows whose updated_at matches their created_at. An insert and an immediate update are indistinguishable, so a real update within the same second of insertion can be missed.
• Triggers poll — they are not live. The grid updates instantly and a Zap does not, and each poll reads the 25 newest rows, so a bulk change can outrun it.
• No delete trigger. A removed row does not start a workflow.
• One workspace per connection. Several workspaces means several connections.
• No field-level filtering on triggers. Every new row fires; narrow it with a Zapier filter step rather than at source.
• Create Row and Update Row take one row at a time. For volume, use the bulk endpoints directly.

The thing this post found

Writing this meant setting the integration up as a new user would, which is how three links on the connection screen turned out to point at docs.schemastack.com — a domain that does not resolve. They sat beside the API key and slug fields: help offered exactly where someone needs it, going nowhere. One had been wrong since the production host moved from .com to .io months ago.

Fixed and promoted as 1.5.1 before this published. That is the whole argument for checking claims before making them — the post was the reason anyone looked.

The Zapier integration guide covers the setup, and outbound webhooks are the other way to push data out when polling is the wrong shape.