-
01 API One schema, every entity over REST.
A developer opens the API console. Every entity in the platform — accounts, orders, invoices, employees, tickets, audit_events — is reachable over a consistent REST API with the same row-level + field-level ACL the rest of the platform enforces. No reverse-ETL window, no semantic-layer translation, no module-specific SDK. The API is the operational table; what the code reads today is what finance closes against this month. Schemas are introspectable; pagination is consistent; rate limits and audit are first-class.
-
REST · one schema
Every entity over one REST API. Introspectable schema, consistent pagination, single-token auth — no module-specific SDK to learn.
API = operational table
What the code reads today is what finance closes against this month. No reverse-ETL window of staleness.
ACL at the data layer
Row + field-level ACL enforced in the database. The API token sees what its role allows — not what the SDK trusts it to.
Rate limits + audit
Per-token rate limits and full API-call audit_events out of the box. The DPO reads the same log security audits.
OpenAPI export
Generate typed clients from the live OpenAPI schema. The contract stays in sync with the database, not with a hand-written spec.
-
02 Events Webhooks both ways, workflows on the same write.
A developer subscribes to order.created. The outbound webhook fires on the same write that posts the row to finance — not on a delayed queue, not from a separate event store. Inbound webhooks run the other direction: an external system POSTs to a signed endpoint and the payload lands as a row or kicks off a workflow. Workflows can fire on the same trigger and chain multiple actions (post to Slack, write to a partner API, draft an AI proposal). Both directions get at-least-once delivery, signed payloads, and DLQ for replay. Workflows have a visual editor for ops + a JSON DSL for developers — same schema, same audit log.
-
Outbound webhooks
Subscribe to any row change. Fires on the same transaction that posts the row — not on a delayed queue.
Inbound webhooks
External systems POST to a signed endpoint. The payload lands as a row or fires a workflow — same ACL, same audit log.
Signed payloads + DLQ
HMAC-signed payloads, at-least-once delivery, dead-letter queue with replay UI. Webhook security as a primitive.
Workflows + webhooks
Same triggers, different consumers. Ops builds visually; developers script in JSON. One audit log.
Replay + dry-run
Replay any past event. Dry-run any workflow against last week's data without side effects.
-
03 Extend Extend in code, on a database that's yours alone.
A developer adds a custom field to the Account record, writes a validation rule in JS, and ships it via the metadata API — no fork, no patch, no upgrade conflict. Custom logic runs in a sandboxed runtime with the same ACL as the user; AI Builder is a programmable surface (propose, ratify, ship) that you can wire into custom code. Your data lives in a single-tenant PostgreSQL database — one schema, one tenant, never co-mingled with anyone else's rows. Your audit log is yours.
-
Metadata extensions
Add custom tables, fields, indexes, validation rules, code, and UI actions through the metadata API. No fork, no patch, no upgrade conflict.
Sandboxed runtime
Custom logic runs in an isolated runtime with the same ACL as the invoking user. No privilege escalation path.
AI Builder as a primitive
Wire AI proposals into custom flows. agent_id and confidence are part of the API contract.
A database that's only yours
Single-tenant PostgreSQL — your rows, never co-mingled in shared tables.
Signed extensions, install in one click, run in the sandboxed runtime with the same ACL the rest of the platform enforces. The substrate ships first; the marketplace follows.
Today: extensions ship via the metadata API + sandboxed runtime, version-controlled in your repo. Tomorrow: a registry of signed plugins from oozmi and partners.
Production vs Pilot
- REST API on every entity with row + field-level ACL
- Inbound + outbound webhooks with HMAC signing, at-least-once delivery, DLQ + replay
- Workflow engine with visual builder + JSON DSL (same triggers)
- Metadata extensions — custom tables, fields, indexes, validation, code, UI actions
- Sandboxed runtime for custom logic with invoking-user ACL
- AI Builder as a programmable surface (propose · ratify · ship)
- Single-tenant PostgreSQL — your own database, your audit log, full pg_dump export
- Plugin marketplace and signed-extension registry
- Typed SDK auto-generation for TypeScript, Go, Python from live schema
- gRPC API surface for service-to-service integrations
- Edge runtime for storefront extensions
Where it fits
Developers compose against AI Builder , Workflows , Ecommerce , CRM , OMS , ERP , and Channels — the same row across every module that wrote it. No second copy, no reconciliation step.
Often read alongside: Operations , Analysts , and Finance & Compliance .
Bring one integration you maintain — we'll show what it looks like as a workflow.
A nightly job that syncs orders to a partner, a webhook chain that breaks every time the schema changes, a custom AR aging script that needs three on-call rotations. Twenty-five minutes. We open the workflow editor against a sandbox, model the integration as a metadata-driven flow with custom logic where you actually need it, and show what the extension surface looks like end-to-end. A real running flow on your data, not a demo deck.