HTTP API reference
Two HTTP surfaces. The app runtime API is what your app calls: data, sign-in, AI, functions, payments, files and topics, under /__appbricx on the app's own origin. The developer API is what the CLI, MCP clients and CI call to build, verify, deploy and operate apps.
App runtime API
- Data APIList, read, create, update and delete rows of the app's tables, plus aggregates, full-text search, lifecycle transitions, external tables, named queries and raw SQL for trusted backends. (21 endpoints)
- Sign-in APIThe app's own end-user accounts: sign-up, password and magic-link sign-in, social sign-in, two-factor codes, sessions, admin user management and organisations. (34 endpoints)
- AI APIChat completions and embeddings with the project's own key or plan credits, metered per app and per user. (2 endpoints)
- Functions, workflows and webhooksCall server functions, queue workflow runs, read runs and dead letters, read notifications, and receive inbound webhooks. (9 endpoints)
- Payments APIOffline and Stripe card payments against the app's order rows. The server computes every amount. (4 endpoints)
- Files APISigned uploads into the project's object store, owner-scoped downloads and soft deletes. (4 endpoints)
- Topics and realtimePublish messages on topics and subscribe to topics and row-changed feeds over server-sent events. (2 endpoints)
- Connector proxyCall a connected integration's action from an app without the app ever holding the credential. (4 endpoints)
Developer API
- Developer APIThe HTTP door the CLI, the MCP server and CI use: tokens, projects, the contract loop (check, apply, patch, verify, deploy) and operating the running app (SQL, rows, schema, snapshots, deploys, runs, tail, secrets). (38 endpoints)
Credentials
- App key + data marker
- A project API key (dpk_c_… in browsers, bound to the app's origins; dpk_s_… on servers) or the builder preview token, plus the data-API marker header. With an app session (the header, or the appbricx_app_session cookie) the call acts as that user under row-level security; without one it acts as a guest. A server key may assert x-appbricx-app-user, x-appbricx-app-role and x-appbricx-app-org.
- App key + signed-in user
- A project key or preview token and a signed-in app session (header or cookie). Signed-out callers get 401.
- Server key
- A server-tier project API key (dpk_s_…, created in the editor under Backend, API). Browser keys and end-user sessions are refused.
- App key + admin session
- A project key and the session of an app user with the admin flag. Anyone else gets 403.
- App key
- A project key or preview token identifies the app. No user session is needed.
- Webhook signature
- No bearer token. When the webhook has a secret, sign the raw body with HMAC-SHA256 and send the hex digest. Hooks with a caller-provisioned secret also accept the secret itself in x-appbricx-webhook-secret.
- Developer token
- A personal access token (apx_pat_…, one workspace, scopes read / apply / deploy), the CLI's browser sign-in token, or the builder session. A project outside the token's reach answers 404, never 403.
- Builder session only
- The signed-in builder session. A personal access token can't mint another token.
Every endpoint
Not in this reference
These routes exist in the source but are steps inside a flow, not APIs to call:
GET /auth/app-oauth/:provider/go: Hop inside the shared Google sign-in flow (sets the browser nonce, then redirects to the provider). Started by GET /__appbricx/auth/oauth/:provider/start, never called directly.GET /files/integration/:filename: Serves files an integration action wrote to temporary storage, by an unguessable name the action returned. Not an API you call.GET /__appbricx/auth/preview-login: One-time preview sign-in link minted by the builder's Backend panel (15 minutes, single use). Returns an HTML page.