prorm control plane

Provision and run databases and data stores.

The API behind prod-orm.io: accounts, provisioning, the long-running cloud
actions that follow, and the billing and teams around them.

Two conventions run through the whole surface.

Nothing takes SQL. A query is described — select, insert, update,
delete — and a schema change is a list of operations. The ORM compiles
those for whichever engine they are going to, which is why the same
definition works on sqlite and postgres, and why no statement a client sends
can reach an engine.

Anything that creates something takes Idempotency-Key. Send one and a
retry replays the first response instead of creating a second thing. The key
comes back on the response either way.

Signing in. A route that takes a bearer token also takes a klock v2
device-signed request (Authorization: Klock <grant> plus an RFC 9421
signature; see the Klock security scheme). What a caller may do is a set
of capabilities; the one each operation needs is in its description and in
x-prorm-capability (needs, the enforcement area, and whether it needs
a fresh stepUp). Whether a missing capability is refused, only audited,
or let through is the area's enforcement mode (CAPABILITY_ENFORCEMENT);
a team member's role is always checked.

Refusals. The klock v2 routes, and every route added with them, answer
{ "error": "<code>", "message": "…" }, the code from the klock error
catalog (KlockErrorCode). Older routes answer { "error": "<sentence>" }.

Base URLs

Environment	URL
production	`https://api.prod-orm.io`
a machine you are sitting at	`http://localhost:3000/api`

Where to go next

Authentication: the ways a request can prove who sent it.

Errors: the shapes a refusal takes and the responses shared across routes.

The reference, grouped as on prod-orm.io: Getting started, Account, Security, Logging and monitoring, Databases, Teams, Billing, Support and Administration.

Introduction

prorm control plane#

Base URLs#

Where to go next#

prorm control plane

Base URLs

Where to go next