Self-storage software API: thirteen endpoints, each behind its own scope.

Ten endpoints read and three write. The reads cover sites, unit types, units, availability, customers as a list and one at a time, rentals, reservations, access events and invoices. Every list endpoint takes a site filter and a cursor, pages 50 rows by default and 200 at most, and refuses a larger page size rather than quietly clamping it.

The three writes are narrow on purpose: record a payment already received, raise a fee already in the catalogue of that site, and end a tenancy or book notice for a future date. The fee endpoint has no amount field at all. The caller names a fee and the engine reads the price and the tax from the catalogue row, so the blast radius of a compromised integration is bounded by what the operator has already priced.

A scope narrows a permission the platform already has; it never invents one. Each scope names the capability a member of staff would need for the same screen, and the endpoint checks both, so granting a partner the rentals feed does not silently hand them the customer directory because the two stand behind one door.

A key holds no role, and several refusals follow from that alone. No scope can write off a balance, issue a partial refund, move a locked-out debtor out or decide a held deposit. Nothing under the API emits a gate code or a tenant access credential, so there is no scope that could grant one. And naming a site the key is not bound to is a 404, never a silently ignored filter that would answer with the other sites of that key.

Yes. Rotation mints a successor carrying the binding, scopes and rate limit of its predecessor, and gives the old key a short bounded life, so both work while the consumer deploys the new value. Three rules keep that from becoming a way round the controls.

The plaintext exists for one function call and is shown once. Everything printed afterwards is the public prefix, which reveals nothing about the secret. Revocation is not cached, so a killed key stops working on the next request rather than at the end of a cache lifetime.

• Rotation never extends a life: a key expiring in two hours still expires in two hours.
• A revoked or expired key cannot be rotated. Create a new one instead.
• The expiry of the successor is chosen by the person rotating, never inherited.

Every request writes exactly one log row, whatever happened, including a throw. The row carries the public prefix, the route template rather than the request URL, the status, the outcome, the scope the endpoint demanded and how long the handler took. That log sits on the key management screen rather than in a file somebody would have to ask for, because what did this key do is the question that gets asked at the worst possible moment.

The rate limit is a column on the row of the key itself, set per key by the operator, and nothing in the request can influence it.

From the endpoint list itself. The reference screen renders the same table the routes are ratcheted against, in both directions, so an endpoint cannot exist without appearing in the reference and cannot appear there without existing. A hand-written reference is correct on the day it is written, is published to people who build against it, and nothing anywhere fails when it stops being true.

The built-in console sends GETs only. The write scopes move real money and end real tenancies with no undo, and a console is a place people click to see what happens; the writes are documented in full, with the idempotency header each one requires, because documenting a thing and firing it from a form are different acts. The console never posts the key back to the application either: the browser holds it and calls the API directly.

Outbound webhooks are tracked per delivery, and a refused delivery is a different kind of fact from a slow one. When the hostname of an endpoint resolves to a loopback or private address at send time, the delivery is refused, the refusal is recorded as a security event, and the site is alerted on the first one.

That record is append-only, so a timeout on the next attempt cannot overwrite it: a security record a later network hiccup deletes is not a record. The subscription is never silently auto-disabled either, because turning it off is a decision for a person taken with the refusal in front of them.

There is no OpenAPI document to hand a client generator, and there is no sandbox tenant. You build against a real site, with a key you have scoped narrowly and can rotate. That is workable, and it is not the same thing as being given a generated client and a disposable dataset to break.

The API also cannot charge a card. It moves no money at a gateway, and the three writes stay deliberately small: record a payment already received, raise a fee already in the catalogue, end a tenancy. An integration that needs to take money from a tenant needs the booking journey or the payment screens, not this.