SynaptaGrid Data
Model the records your business actually keeps — then change their shape without a migration.
Define record types and reusable field groups, nest and repeat them as deeply as the real document does, and get the endpoints and the screens for free. Every version of the model is kept, every change is attributed, and you can go back. Run it on our cloud or keep the data in your own environment.
Read the Data documentationBuild-versus-buy boundary
This replaces platform machinery, not product judgment. The division should be clear before the feature catalogue starts.
Infrastructure replacement, not outsourced product design. Review security and deployment →Review portability and continuity →
The shape
Sections nest, and sections repeat. This is a claim as the business actually files it.
One record type
The same claim, flattened into columns
| claim_ref | item_1_desc | item_1_amt | item_2_desc | item_2_amt | item_3_… |
|---|---|---|---|---|---|
| CLM-1043 | Bumper | 1200.00 | Paint | 640.00 | NULL |
| CLM-1048 | Wiring | 3100.00 | NULL | NULL | NULL |
A fourth line item is a migration. Evidence per item has nowhere to go at all.
The other way out
Put it in a JSON column and the shape survives, but validation, search and any guarantee about what is inside it do not — and every consumer re-implements its own reading of the blob.
Here, the structure is the schema
It validates, it is searchable, it produces the API and the form — and a fourth line item is just a fourth line item.
The payoff
Not scaffolding you then finish — the endpoints, the form and the table, all derived from the one definition.
One definition
Motor claim · published as v3
Appears
A REST API
Plus paging, filtering, sorting and search on the list.
Appears
A working form
Nested and repeating sections render themselves.
Appears
A table to work in
Server-side paging, typed filters, saved layouts.
None of the three is written by hand, and none can drift from the others — there is one definition behind all of them. Change it, publish, and all three move together.
The history
The answer to “what did this say in March”, without reconstructing it from logs.
Claim CLM-1043
Every write, kept
Settlement total back to £4,200
restored from Snapshot 2 by R. Bianchi
Settlement total set to £6,850
M. Okonkwo
Second line item added
A. Whitfield
Claim created
Intake
Going back writes the old values forward as a new snapshot, so the history still shows that someone went back, when, and from where. The snapshot you restored from is never altered.
That distinction is the whole point when somebody later asks what the record said on the twelfth. A log you can rewind cannot answer it.
Getting it out
Signing, backoff, dead-lettering and a log that tells you what happened — the parts you would otherwise write twice.
Delivery log
entity.updated → your endpoint
Signed, so the receiver can trust it
Every payload carries a signature. An endpoint that accepts anything posted to it is an endpoint anyone can drive.
Backoff, then dead-letter
Retries widen rather than hammer a struggling receiver, and what finally fails is set aside instead of lost.
Bulk redrive when you are back
Replay what dead-lettered once the far end is healthy — no re-emitting from your side, no gap to reconcile.
Four destinations
An HTTPS endpoint, Amazon SQS, Amazon SNS or Kafka. Outbound only — ingress is the API.
The change
The step that usually means a migration window, a rollback plan, and someone awake at 2am.
The draft is compared against v2:
Records and integrations follow the version they were on. Rows that would not convert are waiting for you, not gone:
If you have built this before
Everything below is on this page in full. These are the ones that tend to decide it for people who have already solved these problems the hard way.
You have run a breaking schema change against live data before.
You get a plan between the two versions with a column map you review before anything runs. Rows that will not convert are quarantined one by one — so a single malformed record does not halt the migration at 2am, and does not get silently dropped either.
You have shipped a field change and found out downstream what it broke.
The draft is analysed against the live version: which changes are breaking, which need data migrated, which operations keep working. The answer arrives before the change does, not from a support ticket a week later.
You have been asked what a record looked like three months ago.
A snapshot per write, to a depth you choose, with restore to any retained point. The restore is itself recorded, so the history stays honest about what was done to it.
You have written the same CRUD endpoints for the fifth entity this year.
List, read, create, update, delete, bulk and search — plus a schema endpoint per version so your clients cannot drift from the shape the server enforces. No code generation step, no redeploy.
You have written a one-off CSV importer that became permanent.
Every published version registers itself for CSV and JSON in both directions, with a sample file showing the expected shape. Nobody wires it up per record type, and nobody maintains it afterwards.
You have built a webhook sender, then the retries, then the dead-letter queue.
Subscribe your endpoint, a queue or a stream. Payloads are signed, failures retry on a backoff and then dead-letter, and there is a delivery log with per-attempt detail and bulk redrive when your receiver comes back.
You have handed out a shared key because scoping one properly was a project.
Mint a key limited to particular record types, with its own rate limits, and rotate it without downtime. Key holders are always served the published version, never your working draft.
You have reconstructed who changed what from application logs.
A filterable history of every change with a per-record view, and threaded comments on the records and on the schema definitions themselves — so the discussion sits with the thing it is about.
Modelling
Nested, repeating structures that match the real document, built by dragging rather than by migration.
4 capabilities
Sections that nest and repeat, so a document with line items and sub-sections is modeled as it is, not flattened to fit a table.
A record type holds one or more named schemas. A schema is built from sections, and a section can contain other sections or repeat as many times as the record needs — line items, evidence blocks, checklist sub-sections.
Each field carries how it should be presented, so the form is usable without anyone writing form code.
A choice list can be fixed, or it can read live from another record type, another field’s list, a registered database or a REST endpoint.
Referring to another record type is how relationships are expressed: the list resolves at read time, so it reflects the current data rather than a copy made when the field was defined.
Assemble a schema on a canvas from a palette of sections and fields, with a properties panel and validation as you go.
Change
See what a change breaks before you publish it, move the data forward when you do, and go back if you need to.
4 capabilities
Before you publish, the system tells you which changes are breaking, which need data migrated, and which operations keep working.
Each schema has exactly one working draft plus the versions you have published. You analyze the draft against the live version, then publish when you are satisfied.
When a change breaks the shape, you get a migration plan between the two versions — reviewed, run, and with the rows that would not convert set aside rather than lost.
Migrations are classified by how risky they are: a no-op, a mechanical copy, a conversion that may lose precision, or one that needs a transformation you supply. Rows that fail to convert are set aside for review rather than silently dropped or blocking the run.
Turn on history for a schema and every write keeps a snapshot, so a record can be restored to how it looked before.
Restoring writes the old values back and takes a fresh snapshot of the result, so the restore itself is part of the history. The snapshot you restored from is never altered.
A record change can wait for a chosen time, or wait for someone to approve it, before it goes live.
Access
Every record type arrives with its own endpoints, a working interface, search, and a way to get data in and out.
8 capabilities
Every record type and version has its own REST URL space — list, read, create, update, delete, bulk and search — with no code generation and no redeploy.
The service publishes an OpenAPI description with browsable documentation. Each published version additionally exposes its own schema and presentation description, which is what keeps clients and forms in step with the model.
The data entry form and the table are rendered from the schema, so a new record type arrives with a working interface.
Search across a record type with real text search, weighted by which fields matter most.
Paste a sample document or point at an existing database, and the model is proposed for you.
Upload a photograph or PDF of a form and get a proposed schema; upload a filled-in one and get the values extracted against it.
Proposals are drafts. You review, regenerate, or replace the source file before anything is created.
Connect an external database or REST service once, then use it for choice lists and for importing a model.
Upload straight to storage through a short-lived signed link, then attach the file to a record field.
Every published version is available for import and export as CSV or JSON, without anyone wiring it up.
Process
Draw the process, decide what triggers it, and stop for a human decision where a human decision belongs.
1 capability
Records show their current workflow state, their run history, and a funnel you can click through to filter the list.
Operations
Every run recorded step by step, with the controls to restart, rewind, throttle or pause without a deploy.
2 capabilities
A schema can be pinned to its own provisioned database, so the demanding part of your model gets capacity without moving everything else.
If that database cannot be reached, the request fails rather than quietly falling back to the main one. This is a deliberate placement decision you make, not automatic sharding.
Threaded comments with mentions and reactions attach to records and to the schema definitions themselves.
Integration
Any service with an API description becomes usable, and everything that happens here can be pushed back to your systems.
4 capabilities
Subscribe your own endpoints to record events, delivered with a signature, retries and a full delivery log.
Deliveries go to an HTTPS endpoint or to a queue or stream — Amazon SQS, Amazon SNS or Kafka. Failures retry on a backoff and then dead-letter, and you can redrive them from a console.
Mint API keys scoped to specific record types, with their own rate limits, and rotate or revoke them yourself.
Open a chosen schema to anonymous reads when the data is meant to be public — writes stay closed.
Record and schema changes are published to the event stream in the same transaction as the change itself, so the two cannot drift apart.
Updates carry a field-level difference, so a consumer can see what actually changed rather than re-reading the whole record.
One record, one continuous trace
Data governs the record. Automation runs the work around it. Publish a Data model and its record operations become available to Automation; bind the entity, map the fields and arm the workflow without rebuilding a connector.
Run the work, and watch it run →
Trigger contract
The same record, now armed for work.
Data
Publishing the model makes its typed record operations available in Automation. There is no connector to rebuild.
Automation
Choose the record and the lifecycle moments that matter — Created, Updated or Deleted — then arm the binding.
Automation
A step can read the record fresh just before it acts, instead of relying on an older event snapshot.
Both
Every decision, retry and explicit record update remains visible in the workflow run history.
Procurement, invoices, contracts, onboarding and more — each followed from an empty account to a running process, in the order somebody would do it.
The trial runs the same product described on this page.