FlowRunner
PricingContact
Theme
Start Free

Ninox

Database

Read and write your Ninox low-code databases: agents browse teams, databases, and tables, list and filter records, create or update them in bulk, and run Ninox script queries to aggregate data across tables.

8 actions API key available
Ninox website ↗ Platform Documentation ↗ Capability data verified 2026-07-27
A completed payment confirmation arrives from the payment processor
List Tables reads the invoices table's field definitions so the match uses real field names
List Records filters the table by invoice reference and amount
The agent verifies exactly one open invoice matches, and that the paid amount equals the invoiced amount
Create or Update Records marks the matched invoice paid with the payment reference stamped on it
Payments that match nothing, match twice, or arrive short go to the bookkeeper with the candidates side by side
Run Query recomputes the week's outstanding balance across the table after the batch settles
The channel receives the reconciliation summary: matched, flagged, and outstanding

What This Integration Enables

Teams build Ninox databases because the off-the-shelf tool did not fit: the invoicing app that matches how they actually bill, the inventory base shaped like their actual warehouse. The trap is that a database this custom becomes an island, fed by hand while the events it describes happen in Shopify, Stripe, and email. FlowRunner agents put the custom database back at the center: records are created and updated in bulk as events fire elsewhere, lookups and filters run inside automations, and Ninox script queries turn the base into a live reporting engine. - Sync records between Ninox and CRMs, storefronts, and spreadsheets in both directions - Create or update records in bulk from a single call when events fire in other systems - Look up a record or filter a table by field values as a step inside any automation - Run Ninox script queries to aggregate and compute across tables without exporting - Discover teams, databases, and tables at runtime so flows adapt as the base evolves Because a Ninox base is usually the operational system of record for the team that built it, its one irreversible operation runs behind a [human-in-the-loop](/concepts/human-in-the-loop) gate.

Without FlowRunner

The database only knows what got typed Orders, payments, and updates from other systems reach Ninox when someone remembers to enter them
Reconciliation is a side-by-side scroll Payment reports and invoice records get matched by eye, and short payments slip through
Aggregates assembled by export Weekly numbers mean exporting tables and rebuilding sums in a spreadsheet

With FlowRunner

Events write themselves in Orders and payments land as records in bulk the moment they happen elsewhere
Matching runs continuously Agents filter by field values, verify amounts, and only ambiguity reaches a person
Ninox script does the math in place Run Query aggregates and computes across tables, and results flow straight to reporting

Use Case Scenarios

Orders arrive as records, not as a to-do

A [Shopify](/integrations/shopify) order fires. The agent maps it to the fulfillment base's fields and calls Create or Update Records to log the order with customer, items, and status in one write, then posts to [Slack](/integrations/slack) so the team sees the new work inside the database that already runs their day. Bulk imports use the same call: fifty records in one request instead of fifty manual entries.

Payments reconcile against the base

When [Stripe](/integrations/stripe) confirms a payment, the agent uses List Records with a JSON filter to find the customer's open invoice, verifies the amount, and calls Create or Update Records to mark it paid. Everything that matches cleanly settles at machine speed; the bookkeeper only ever sees the exceptions, each one presented with the payment and the candidate records together.

The weekly report writes itself

On Friday afternoon, the agent executes Run Query with a Ninox script that selects, filters, and aggregates the week's records across tables: revenue by category, open orders by age, whatever the script computes. Results append to [Google Sheets](/integrations/google-sheets) for stakeholders who will never open Ninox, and the same numbers post to the channel. The report inherits every improvement made to the script, because the logic lives in one place.

Human-in-Loop Highlight

Delete Record permanently removes a record from a Ninox table, and in a base the team built themselves, that record is rarely just a row: it is an order some view counts, a customer some printout references, a line the year's numbers include. The API cannot undo it, so FlowRunner cleanup flows never treat deletion as hygiene. When an order is cancelled upstream or a duplicate surfaces, the agent pulls the full record with Get Record and puts the real question to the owner: delete it, or keep it and mark it cancelled so history survives? That is a business decision about what the base should remember, not a data operation, and it belongs to the person who answers for the numbers. Only the records a human has ruled on reach Delete Record.

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

8 actions

Structure

3
  • List Teams Lists the Ninox teams the API key can access, each with id and name. The starting point for discovering where a base lives.
  • List Databases Lists the databases within a team. Database ids anchor every table and record operation.
  • List Tables Lists a database's tables with their field definitions. The schema read that keeps writes mapped to real field names as the base evolves.

Records

4
  • List Records Retrieves records from a table with JSON field-value filtering, sorting, and paging. The lookup and match step inside sync and reconciliation flows.
  • Get Record Retrieves a single record by its numeric id with its full fields object. The context pull before any decision about a record's fate.
  • Create or Update Records Creates or updates one or more records in a single call: items with an id update existing records, items without one create new records. The bulk write behind every event-driven sync.
  • Delete Record Permanently deletes a single record by id. Cannot be undone, and the operation this page's human gate exists for.

Queries

1
  • Run Query Executes a Ninox script query against the database and returns the raw result. Ninox script selects, filters, aggregates, and computes across tables, which makes this the reporting engine of the connector: the result shape is whatever the script defines.

Frequently Asked Questions

What can FlowRunner do with Ninox?

FlowRunner agents can run List Teams, List Databases, and List Tables in Ninox, plus 5 more actions.

Does connecting Ninox to FlowRunner require OAuth?

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

Can Ninox trigger a FlowRunner workflow automatically?

Ninox doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Ninox

$100 in credits. No card required. Connect in minutes.