Zite DB

Zite DB is the database behind Zite's no-code AI app builder, with databases containing tables containing records, a SQL read layer and webhooks. Agents manage databases, tables and fields, create, update and upsert records in bulk, aggregate and query with SQL and react to database events.

Verified 1 trigger 25 actions API key available

Zite DB website Platform Documentation Capability data verified 2026-08-27

On Database Event fires when a record is created in the orders table

The agent reads the delivery's source metadata and ignores changes its own writes caused

Get Record returns the full record behind the event, with the previous values on an update

Run SQL Query checks the order against the customer's history in one read-only statement

Update Record writes the derived risk band onto the order

The agent posts the order and the reasoning to the review channel

The operations reviewer decides whether the order ships or goes to manual verification

What This Integration Enables

Zite DB is the database behind Zite's no-code AI app builder, which means a FlowRunner agent and an app someone assembled by describing it are writing to the same store. That shared surface is the reason to automate it carefully rather than enthusiastically: changes arrive from a person in the interface, from an import, from another automation platform, and from your own flows, and telling them apart matters.

Zite makes that possible in an unusually direct way. The On Database Event trigger delivers the event type, a unique event identifier for idempotency, the changed records, and on updates the previous values alongside the new ones, and its metadata states the source of the change as the interface, the public API, an import, or a named automation platform. Reading that field is how a flow stops reacting to its own writes without maintaining a shadow ledger of what it just did. Deliveries are signed, and this trigger rejects one whose signature does not verify. On the read side, Aggregate Records computes sums, averages, and counts on Zite's side with grouping, and Run SQL Query executes SELECT statements only, with numbered bind parameters so a caller-supplied value is never parsed as SQL. Together they mean an agent can answer a question about the data without moving the data.

Without FlowRunner

Flows that react to themselves An agent writes a record, the write raises an event, and the agent processes its own output as new work

Analysis by pagination Answering a question about the data means pulling every record into the flow and computing it there

Upserts that duplicate A matching key that resolves to nothing is treated as a batch of new records, and the call reports success

With FlowRunner

Origin-aware triggers Every delivery states where the change came from, so a flow can ignore the changes it caused

Answers computed at the source Aggregates and read-only SQL run on Zite's side and return the figure rather than the rows

Matching confirmed once The field identifiers behind an upsert are resolved and checked before the first run, not discovered from the duplicate count

Use Case Scenarios

Order review that does not chase its own tail

On Database Event fires on record creation in the orders table. The agent checks the delivery's source first and drops anything its own writes produced. For a genuine new order it calls Get Record, then Run SQL Query to read that customer's history in a single read-only statement rather than paging their past orders into the flow. The derived risk band goes back with Update Record, the payment state is confirmed against Stripe, and anything above the review threshold posts to Slack instead of shipping.
A daily figure nobody exports

Operations needs revenue by region every morning. Aggregate Records computes the sum grouped by the region field, filtered to the period, entirely on Zite's side. The result lands in a sheet in Google Sheets next to the same period from the CRM in HubSpot. Nothing is paged, nothing is summed in the flow, and the number is the database's own answer rather than a reconstruction of it.
Loading a batch that updates instead of duplicating

A supplier file arrives. The agent calls List Fields to resolve the field identifiers for the matching key, because the upsert accepts identifiers only for matching even though the record keys themselves take names or identifiers. Bulk Create Or Upsert Records then applies the batch, updating matched rows rather than duplicating them. Rows that do not match on the key are created, and the created and updated counts post to the team with the file name, so the shape of the load is visible without anyone querying for it.

Human-in-Loop Highlight

The most expensive mistake on this API succeeds. Bulk Create Or Upsert Records becomes an upsert when it is given matching fields, and those must be field identifiers: the record keys themselves accept field names or identifiers, but the matching parameter does not. Give it a field name and it matches nothing, so every incoming row is treated as new, the call returns a normal success, and the table gains one duplicate for every record the flow meant to update. Nothing raises. The only symptom is a row count that is wrong later, and there is no reverse of an upsert.

So the agent resolves the identifiers with List Fields, then stops before the first run against a table it has not written to before: "Bulk Create Or Upsert Records is about to load 4,206 rows into Suppliers, matching on the field with identifier fld_8k2c, which List Fields reports as the column named Tax ID. If that is the wrong field, all 4,206 rows will be created as new records and the call will report success. Confirm the matching field?" A person confirms the mapping once, and after that the flow runs unattended against a key that has been checked. That is the shape FlowRunner reaches for whenever the failure is silent and the cost scales with the batch: not a person watching every run, but a person present at the moment the run's assumptions are set.

Agent processes routinely

Detects exception requiring judgment

Clear match Continues automatically

Ambiguous Routes to human via preferred channel

Human decides

Agent resumes with decision

Agent Capabilities

25 actions

Databases

List Databases Returns every database the key can reach, with its identifier and name. That identifier is the short id visible in the app URL, not a UUID.
Create Database Creates a database together with its tables. Tables cannot be added in a second step of the same call, so supply every table the database should start with.
Get Database Returns one database with its tables and their fields. Used to discover table and field identifiers before reading or writing.
Delete Database Permanently deletes a database and every table and record inside it. There is no undo on this API.

Tables

Create Table Creates a table with the fields specified. Every field takes a type from Zite's own vocabulary, and leaving the template off takes that type's defaults.
Update Table Renames a table. The name is the only table level property this API exposes for update.
Delete Table Permanently deletes a table and every record in it. There is no undo on this API.

Fields

List Fields Returns every field on a table with its identifier, name, type, and configuration. The call that supplies the identifiers upsert matching requires.
Create Field Adds a field to a table. The type must be one of Zite's twenty field types, and each accepts its own template of options: select choices, number precision, currency symbol, linked table, and so on.
Update Field Renames a field or replaces its configuration. At least one of the two must be supplied, which the operation checks before calling.
Delete Field Permanently deletes a field and every value stored in it. There is no undo on this API.

Records

List Records Returns records with filtering, sorting, and paging. This is a POST because the filter is a nested object rather than a query string, and filters support nested and and or logic.
Get Record Returns a single record by identifier. Record identifiers are UUIDs here, unlike database and table identifiers, and supplying the wrong shape produces a distinct error rather than a not found.
Create Record Adds one record, keyed by field name or field identifier, so a flow can write by human-readable names without looking identifiers up first.
Update Record Updates one record, writing only the fields included and leaving every other cell as it was.
Delete Record Permanently deletes one record. There is no undo on this API.
Bulk Create Or Upsert Records Creates many records in one call, and upserts instead when given matching fields. Matching accepts field identifiers only, not names, even though the record keys accept either, which is why this page's human gate sits here.
Bulk Update Records Updates many records in one call, each entry carrying its record identifier alongside the fields to change. Only the fields present are written.
Bulk Delete Records Permanently deletes many records in one call, by their identifiers. There is no undo on this API.
Aggregate Records Computes a sum, average, minimum, maximum, count, or distinct count over one field, optionally filtered and grouped by another. Used instead of paging every record into a flow to add a column up.

SQL

Run SQL Query Runs a read-only SELECT statement and returns the rows, referencing tables and fields by their human-readable names. Numbered bind parameters carry the values, which is what keeps a caller-supplied value from being parsed as SQL.
Get SQL Schema Returns the SQL view of a database's schema: table names and, optionally, every column with its type, as they must be spelled in a statement. Called before a query so the statement references names that exist.

Webhooks

Create Webhook Creates a webhook subscription on a database and returns its identifier and signing secret. The secret is returned only on creation and cannot be retrieved later, so it has to be captured here.
List Webhooks Returns every subscription on a database with its url, subscribed events, table filter, and active state. The signing secret is never included.
Delete Webhook Permanently removes a subscription. The signing secret goes with it, and recreating the subscription issues a new one.

Triggers

1 triggers

Event Triggers

On Database Event Fires when a record, table, or field changes in a Zite database. Choose which of the nine event types to listen for and optionally narrow to a single table. Each delivery carries the event type, a unique event identifier for idempotency, the changed records, the previous values on an update, and the source of the change, which is how a flow avoids reacting to its own writes.

Frequently Asked Questions

What can FlowRunner do with Zite DB?

FlowRunner agents can run List Databases, Create Database, and Get Database in Zite DB, plus 22 more actions.

Does connecting Zite DB to FlowRunner require OAuth?

No. Zite DB connects to FlowRunner with an API key, no OAuth flow required.

Can Zite DB trigger a FlowRunner workflow automatically?

Yes. Zite DB supports 1 trigger that can start a FlowRunner workflow automatically.

Start building with Zite DB

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us