Wire compatibility

Kethosbase's REST, Auth, Storage, and Realtime APIs speak a widely-used BaaS wire protocol. Many existing JavaScript client libraries that target that protocol work against a Kethosbase project unchanged — you point one at your project URL and key.

This exists so a team with an application already written against a compatible client can move to Kethosbase without a rewrite: the same library, the same method calls, a different endpoint and key. For new code we recommend the first-party JavaScript SDK (@kethosbase/client) — it targets these same APIs, ships TypeScript types, and is the surface we document and support directly.

Point a compatible client at your project

Every compatible client is created the same way ours is — a project URL and an API key. Use your project's base URL and the publishable key (kbp_…) for anything that ships to a browser or device; Row-Level Security decides what it can see. Keep the secret key (kbs_…) on your own backend only.

// Whatever compatible client you already use, the shape is the same:
const client = createClient(
  "https://<project-ref>.kethosbase.com",
  "kbp_<publishable-key>"
);

const { data, error } = await client
  .from("todos")
  .select("id, task, done")
  .eq("done", false)
  .order("id", { ascending: false })
  .limit(20);

The URL and keys are on the project's Overview page in the dashboard. Nothing else about the client changes.

What is covered

The compatible surface is the four project APIs, each documented in full on its own page:

Area	Works through
Database	The REST data API — filters, ordering, pagination, embedding, insert / update / upsert / delete, and RPC.
Auth	Authentication — email + password, one-time codes and magic links, anonymous sessions, and social sign-in. Sessions carry the `authenticated` role so your RLS applies.
Storage	The Storage API — buckets and objects, uploads and downloads, signed URLs, and public objects.
Realtime	Realtime — broadcast channels and database change feeds over WebSocket.

Things to know

Keys are Kethosbase keys. Authenticate with your project's opaque kbp_… / kbs_… keys (see the Overview), not keys minted by another platform. A compatible client sends whatever key you configure as the bearer token, which is all Kethosbase expects.
Row-Level Security always applies. The wire protocol does not change who can read or write a row — your RLS policies do. The publishable key is anon; a signed-in user's token is authenticated; the secret key is service_role and bypasses RLS, so keep it server-side.
Some advanced grammar is still growing. A few PostgREST-style features are not implemented yet and answer with a clear 400 rather than misbehaving — see the deferred list on the REST page. A compatible client that emits one of those will get that error back.
Use our own tooling for the dashboard and migrations. Wire compatibility covers the runtime data APIs, not project management — use the dashboard and the Kethosbase CLI to create projects, run migrations, and manage keys.

Compatibility is a property of our API, offered so you can reuse code you already have. It is not an affiliation with, or endorsement by, any third-party project. For the fullest and best-typed experience, build new work on the first-party JavaScript SDK.