API reference · Management plane

SQL and logs under an account key

Run SQL on a project from the management plane, read its statement history, and read its request log.

Host: https://api.manybases.com · Key: ak_.

SQL#

Everything in SQL applies. One difference: a destructive statement — one that does not name its target — requires a signed-in human in addition to the two-step confirmation. Without X-Account-Session the account key receives 401 and no token is issued; with it, the first call answers 428 and the second, with confirmation_token, executes. An account key acts for a human who has to be there; a project's own server key confirms itself.

apply_migration has no route of its own: it is an alias of run_sql for CREATE, ALTER and DROP TABLE, with the same guard rails. There are no versioned migrations.

The request log#

GET /v1/projects/:pid/logs (tool get_logs) returns the requests made to the project — the stream the dashboard's Logs screen shows and the one an agent reads to debug an app.

Each entry has thirteen fields:

{ request_id, ts, method, path, status, error_code, level, message,
  plane, replay, key_id, account_session_id, actor }

• level is info or warn. warn marks notable events, such as a table created without a preset or a preset change; message then carries the text, and is null otherwise.
• plane says which class of key made the request: data (the app's traffic, pk_ and sk_), management (agent and dashboard, ak_), unknown (no key, or an unknown key — probing 401s land here). It is derived from the key, never from the path.
• actor is human when a valid account session accompanied the request and agent otherwise. human means "a signed-in human was there", never "a human acted".
• key_id is the id of the key presented — the one the key list shows, and that revoke_key and rotate_key take — never its value. The two values of a rotating key are two distinct key_ids. Entries written before the fix of 2026-09-19 carry instead the id the key service gave the key, until they are purged. account_session_id is set when a valid account session was present.
• replay is true when the response came from the idempotency store and the operation was not redone.
• request_id is the same id the refused call returned in its X-Request-Id header.

Filters are the standard ones: ?status=gte.400&plane=eq.data&order=ts.desc&limit=50, with cursor pagination. path filters on the route template (like.*rows*), key_id accepts in.(…) — which is how a function's requests are found, from the log_key_ids its card publishes. The default sort is ts.desc. There is no default plane filter: without ?plane= the route returns everything, and an agent reading only its app's traffic passes plane=eq.data itself.

Retention is 30 days and 5 000 entries, purged when an entry is written — so a project that receives no traffic keeps its last entries longer than 30 days. Execution output of an edge function (console.log, CPU overruns) is not readable through any tool or screen yet; only the requests a function makes to its project's API appear here.