Data API
A REST API for every table, written for you and secured by default.
Screens, workflows, scripts and outside tools all read and write through the same data API. It covers every table, describes itself in OpenAPI, and applies each caller's access and business rules on every request.
- GET/__appbricx/api/v1/appointment2003 rows, the patient's own
- POST/__appbricx/api/v1/appointment422That time is not available.
- GET/__appbricx/api/v1/search?q=flow200full-text, filtered by access
- POST/__appbricx/queries/todays_schedule20014 rows
- GET/__appbricx/api/v1/openapi.json200every table, described
- Every table
- List, get, create, update, delete
- OpenAPI
- /__appbricx/api/v1/openapi.json
- Search and aggregates
- Full-text search, counts and sums
- Access applied
- Row-level security on every call
How the data API works
Apply the contract. Each table appears at /__appbricx/api/v1/<table> with list, get, create, update, delete and aggregate, plus lifecycle transitions for status fields.
Screens call it through the React SDK (app.query, app.create, app.transition); outside tools call it over HTTP with a server key from Backend, API.
Every request runs as the caller: Postgres row-level security decides which rows they see, and business rules refuse bad writes with your message.
# signed in as a patient: only their own rows come back
GET /__appbricx/api/v1/appointment
200 3 rows
# full-text search across tables
GET /__appbricx/api/v1/search?q=sunrise
# a named SQL query with parameters
POST /__appbricx/queries/todays_schedule
{ "day": "2026-10-12" }
200 14 rows
# the whole API, described
GET /__appbricx/api/v1/openapi.json
What the data API covers
CRUD for every table
List with filters, sorting and paging; get, create, update and delete one row. Platform columns are filled for you.
Aggregates
Counts, sums and group-bys from /aggregate, for dashboards without custom endpoints.
Full-text search
One search endpoint across the app's tables, still filtered by what the caller may read.
Named queries
SQL queries with parameters and caller scopes, for reports the CRUD endpoints don't cover.
External tables
Existing Postgres tables can be served through /ext with the same access model.
OpenAPI description
Point a client generator, an API tool or another agent at openapi.json and it knows every route.
Atelier serves three roles from one API
Atelier's buyers, makers and curators all read products and orders through the same data API. A buyer sees their own orders, a maker the orders for their pieces, and a server rule stops anyone but a curator approving a piece.
Works with
Data API: common questions
Do I have to write API endpoints?
No. Every table in the contract gets list, get, create, update, delete and aggregate endpoints, plus search and lifecycle transitions. Write a server function only for logic the data API doesn't cover.
Is the API secure by default?
Yes. Every request runs as the caller, Postgres row-level security filters the rows, and business rules check each write. Hiding a button is never the only protection.
Is there an OpenAPI spec?
Yes. Each app serves its description at /__appbricx/api/v1/openapi.json.
How do outside tools authenticate?
Server-side callers use a server key from Backend, API. Browser screens use the signed-in user's session, held in an HttpOnly cookie.