PostgREST-compatible SELECT endpoint backed by Turso SQLite.

camelCase column names in select, order and filters are automatically converted to snake_case, matching the request-body behaviour of POST/PATCH.

Authentication

• Public tables (configured via security policy) can be read without a token (capped at 100 rows per request for unauthenticated callers).
• All other tables require a valid bearer token.
• Service-role tokens bypass row-level security (RLS).

Row-Level Security (RLS) When authenticated with a non-service token and the table is not public, a WHERE user_id = <caller_id> filter is automatically appended (the owner field name is configurable via the project's security policy).

Tables configured with read: "membership" are instead scoped via a junction table: WHERE <row_field> IN (SELECT <resource_field> FROM <membership_table> WHERE <user_field> = <caller_id>), so every member of a scope (e.g. all staff of a hostel) can read its rows.

Filtering — column operators

SQLite's LIKE ignores ASCII case, so like and ilike match alike. neq and a non-empty not.in never match a NULL. A boolean value (eq.true, eq.1, is.true, an in item) also matches the text 'true'/'false' this API stores booleans as. Repeat a column to apply several conditions to it: ?price=gte.10&price=lt.20. Any other PostgREST operator (cs, fts, eq(any), …) and the SDK's not_in are a 400 with code PGRST100 naming it; a value that does not start with an operator is plain equality.

Logical groups

• ?or=(col1.eq.val1,col2.gt.5) — any condition must match
• ?and=(col1.eq.val1,col2.gt.5) — all conditions must match
• ?not.or=(…) / ?not.and=(…) negate a group; nest groups as or(…) / and(…)
• Quote values containing , ( ) & ": ?or=(name.eq."Smith, John",tier.eq.vip)
• The older key form ?or(col1.eq.val1,col2.eq.val2) is still accepted

[
  {
    "id": 1,
    "name": "John Doe",
    "email": "john@example.com",
    "status": "active",
    "created_at": "2024-01-20T10:30:00Z"
  }
]