All engineering notes
ArchitectureSeptember 12, 20264 min read

The console is a client of the same API

There is no privileged browser backend. The dashboard reads keys and runs commands through the same data-plane service your application calls.

Internal tools tend to drift from the public contract. They get a private endpoint, a bypass flag or a direct database connection, and then they stop being useful as a test of the real product.

Same endpoints, different authentication

The key browser calls GET /api/data/{dbId}/keys. The command console calls POST /api/data/{dbId}/command. Key edits use the same command and pipeline endpoints, and the string form uses PUT /api/data/{dbId}/strings/{key}. The dashboard authenticates with your session token; your application authenticates with a scoped API key. Both paths land in the same service, permission checks and quota enforcement.

That means a command that works in the console follows the same validation and quota rules as the same command from a server. The console is a convenience, not an escape hatch.

Why this matters

When the browser and the SDK share one service, a bug reproduced in the console is a bug in the product path. There is no second implementation to keep in sync and no internal schema that diverges from the public one.

It also keeps authorization honest. The console cannot read a database the signed-in user does not own, because the service applies the same owner lookup it applies to an API-key request. The UI never receives a broader view than the API would return.

  • The browser session is not a superuser credential for the data plane.
  • Read-only keys and archived databases are enforced in the service, not hidden by the UI.
  • The landing-page demo is explicitly local and labeled; it never claims to be connected.

Where the demo stops

The marketing site includes a small command sandbox so visitors can feel the interaction model without an account. It runs entirely in the browser, resets on refresh and says so. Real commands require a verified account and a database, because a real command needs a real scoped key.

Keeping that boundary visible is part of the design. A fake console that implies live execution would be worse than no console at all.

Try the contract yourself.

Five databases are free. Create one, mint a scoped key and send a command.