API Endpoints ​

All endpoints are under /api/v1/. Table routes are at /api/v1/table/{table}/.

For JavaScript examples of every operation, see the Frontend Guide. Your running server also has interactive docs at /api/v1/doc/ui (Swagger UI).

Database Level ​

Table CRUD ​

All CRUD endpoints respect row-level security rules defined in your config.

INSERT — POST /table/{t}/insert ​

{
  "values": { "title": "Hello", "body": "World" },
  "returning": "*"
}

Common mistake: Sending {"title": "x"} without the values wrapper: the request fails with 400 Error parsing INSERT data (with RESPOND_WITH_ERRORS, the detail says Insert query must have either values or expr).

SELECT — GET/POST /table/{t}/select ​

GET with query params:

/table/{t}/select?where=published == true&order=-created&limit=10&select=id,title

POST with JSON body:

{
  "where": "published == true",
  "order": "-created",
  "limit": 10,
  "select": "id,title"
}

Returns: array of records.

LIST — GET/POST /table/{t}/list ​

Same parameters as SELECT. Returns { items: [...], total: number }.

VIEW — GET /table/{t}/view/{id} ​

No body. Returns single record or 404.

Optional query params: select (field filter), where (additional filter).

UPDATE — POST /table/{t}/update ​

{
  "where": "author_id == 'abc123'",
  "setValues": { "published": true },
  "returning": "*"
}

REPLACE and rules: SQLite resolves an OR REPLACE conflict (primary key or unique column) by deleting the existing row, and that delete never goes through deleteRule or updateRule. So on a table with a rules extension, a non-admin request that uses REPLACE (including EDIT with or=INSERT) gets 403, unless deleteRule is 'true' (no trigger on that event, never on auth tables). Admin requests and public: true tables are not affected. For a rule-safe "create or update", see User Preferences (Upsert).

EDIT — POST /table/{t}/edit/{id} ​

{ "title": "Updated Title" }

Body is bare fields — NOT wrapped in setValues. The endpoint wraps it internally.

DELETE — POST /table/{t}/delete ​

{
  "where": "id == 'abc123'",
  "returning": "*"
}

Authentication ​

Available when a table has the auth extension. See the Frontend Guide for complete auth flow examples.

Sign Up — POST /table/{t}/auth/sign-up ​

{
  "username": "testuser",
  "email": "test@example.com",
  "password": "mypassword",
  "passwordConfirm": "mypassword",
  "name": "Test User"
}

Body is bare fields matching the auth table schema. Returns { token, refresh_token, record }. passwordConfirm is required (and must match) when the auth extension sets passwordConfirmSuffix: 'Confirm', as the with-auth scaffold does; without that option, omit it.

Login — POST /table/{t}/auth/login-password ​

{
  "identity": "test@example.com",
  "password": "mypassword"
}

The identity field accepts email or username. Returns { token, refresh_token, record }.

Other Auth Endpoints ​

Authenticated Requests ​

Add Authorization: Bearer <token> header to any request that needs auth context (for rules like auth.uid == id).