Do we use this today?

Not in daily work. One versioned endpoint is published, for projects, and no part of the growth workflow depends on an API key. The capability exists so that a script or an internal tool can be connected without building authentication, scopes and limits first.

Can a key secret be recovered after it is created?

No. Only the SHA-256 hash is stored. If a secret is lost, revoke that key and issue a new one. The constraint is deliberate rather than an omission.

How are test and live keys kept apart?

Tokens are prefixed dsk_test_ or dsk_live_, and authenticateApiKey rejects a key whose environment prefix does not match the environment it is presented to.

How do I add a versioned endpoint?

Declare it in src/registries/api-lifecycle.ts, add a file route under src/routes/api/v1/ that calls authenticateApiKey with the scope it needs, and keep request and response shapes behind shared Zod contracts. src/routes/api/v1/projects.ts is the working reference.

What happens on every API request?

authenticateApiKey parses the bearer token, matches its environment prefix, verifies the SHA-256 hash with a timing-safe comparison, checks the required scope and reserves the api.requests.minute quota, all before feature code executes. Issuing a key is an idempotent admin command: replaying the same mutation ID returns the original receipt marked as secret unavailable instead of minting a second secret.

The foundation under itDeveloper platform

API keys and endpoints

A scoped, versioned API for anything we later want to script.

Growth-OS can issue API keys with scopes, per-minute limits and versioned endpoints. One endpoint is published today, for projects, and nothing in our daily work depends on it. It is here so that connecting a script or another internal tool later is a configuration change rather than a project of its own.

SHA-256hashing on every stored secret1time a secret is ever shown3checks before feature code runs

Open Growth-OS See it working

14 of 22 in The foundation under it

Product example

See it working

This is the same visual component used by the authenticated app, rendered with deterministic sample data.

Scenario

viewport

surface theme

mode

Configured

The real API key, quickstart, endpoint and delivery views, side by side.

Inert sample data · no network access

API keys

1 active

A key lets a script or another system read this workspace through the versioned API. The plaintext key is shown once at creation; only a verifier is stored.

Production reportingActive

sk_live_8f31…projects:readusage:readNo expiry dateLast used Aug 13, 2026

Create a key

The plaintext key appears once, right after you create it.

Quickstart

The starter exposes the released, versioned projects read API. More scopes appear here as their routes ship.

curl https://your-app.example/api/v1/projects \
  -H "Authorization: Bearer sk_live_..."

Outbound webhooks

1 enabled

Each endpoint receives signed, versioned events over HTTPS with bounded retries.

Production receiverEnabled

https://example.com/hooks/saasorganization.updatedsubscription.updatedLast delivery Aug 13, 2026, 8:00 AM

Add an endpoint

The signing secret appears once, right after you add the endpoint.

Recent deliveries

1 need attention

Every event sent to an enabled endpoint, with the attempts it took. Failed and stopped deliveries can be replayed during the retention window.

Event	Status	Attempts	Response	Created	Action
subscription.updated	Delivered	1 attempt	HTTP 200	Aug 13, 2026, 7:59 AM	Nothing to replay
organization.updatedReceiver unavailable after the bounded retry policy.	Stopped retrying	8 attempts	HTTP 503	Aug 13, 2026, 7:30 AM

Highlights

Why it matters

A secret exists once

A key is hashed with SHA-256 before storage and shown a single time. A copy of the database carries nothing worth stealing.

Three checks before any handler runs

The key, its scope and its per-minute allowance are verified before a request reaches feature code.

Versions and dates declared up front

Each endpoint registers its version, stability and retirement dates, so changing it is a decision rather than a surprise for whatever depends on it.

The problem this solves

Without a shared foundation, every team rebuilds these edge cases, differently.

Keys you can read back

A hand-rolled key table usually stores the secret itself. One copied backup and every key is compromised at once. Storing only a hash means there is nothing there to leak.

The field that can never change

An endpoint ships with no version, something starts depending on every field in the response, and now every change is a breaking change. Declared versions and retirement dates keep that conversation possible.

One loop consumes everything

A script with a bug hammers the API and everything else slows down. Adding limits to a live API afterwards is painful, so keys carry a per-minute allowance from the first request.

How it works

The mechanism end to end, as implemented in the repository.

1
An admin creates a key
The secret is generated on the server, hashed and shown once. If it is lost you revoke and reissue; reading it back is deliberately impossible.
2
Endpoints declare their contract
Each route registers its version, request and response shapes, and rate-limit key before it ships, so compatibility is written down rather than remembered.
3
Requests pass three gates
The server verifies the key, checks its scope and reserves rate-limit quota. Only then does the handler touch data.
4
Keys retire rather than vanish
Revoking stamps a timestamp instead of deleting the row. The key stops working immediately and the history of what it did survives.

Engineering guarantees

What this does and does not promise

Safety boundary

The key shown in the preview is fake and authenticates nowhere. Real secrets are minted only inside authenticated admin commands, and test and live keys are separated by prefix so one can never be used in place of the other.

Implementation evidence

The boundary above is code, not a claim. These files carry the contract:

src/features/developer-platform/server.ts
src/server/api-key-auth.ts
src/registries/api-lifecycle.ts
src/routes/api/v1/projects.ts

Questions

Frequently asked questions

Used alongside this

These capabilities share contracts and boundaries with this one.

Outbound webhooks

Signed events another system can subscribe to. Three exist today.

Usage limits

AI spend is capped by the server, at the moment of the write.

Workspace audit trail

Who was invited, whose role changed, who exported, who recovered.

What api keys and endpoints rests on

The docs describe the same contracts this page demonstrates.

Read the docs See the whole directory