Skip to content
Wow your usersDeveloper platform

Your customer API

Give your customers API keys without building the scary parts yourself.

Your customers get real API keys with scopes, limits, and versioned endpoints. Secrets are shown once and stored hashed, so a leaked database can't leak keys. Every request is checked before your code even runs.

SHA-256hashing on every stored secret1time a secret is ever shown3checks before your code runs: key, scope, limit
See it working

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

Explore the actual API key, quickstart, endpoint, and delivery components together.

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.

Name it after the system that will use it, so you know what stops working when you revoke it.

A short life limits the damage of a leaked key.

Scopes

A key can only do what its scopes allow.

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.

The receiver has to answer within the retry window.

Events

Only the events you pick are sent to this 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.

EventStatusAttemptsResponseCreatedAction
subscription.updatedDelivered1 attemptHTTP 200Aug 13, 2026, 7:59 AMNothing to replay
organization.updatedReceiver unavailable after the bounded retry policy.Stopped retrying8 attemptsHTTP 503Aug 13, 2026, 7:30 AM

Preview ready

Highlights

Why it matters

Secrets stay secret

Keys are hashed before storage and shown exactly once. Even a leaked backup has nothing worth stealing.

Every request gets checked

The key, its scope, and its rate limit are all verified before any customer data is touched.

Versioned from day one

Every endpoint declares its version and retirement dates up front, so you can evolve your API without surprise breakage.

The problem this solves

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

The backup that leaked every key

Hand-rolled key tables tend to store secrets you can read back. One leaked backup, and every customer's key is compromised at once. Here only hashes are stored, so there is nothing to steal.

The field you can never remove

You ship an endpoint with no versions. Customers build on every response field. Now every change is a breaking change, and every release turns into a support fire.

One script eats the whole API

A customer's runaway loop hammers your API, and everyone else's requests crawl. Bolting rate limits onto a live API is painful. These keys ship with per-minute limits from the very first request.

How it works

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

  1. 1

    An admin creates a key

    The secret is generated on the server, hashed, and shown exactly once. If it's lost, you revoke and reissue. Reading it back is deliberately impossible.

  2. 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 instead of tribal knowledge.

  3. 3

    Requests pass three gates

    The server verifies the key, checks its scope, and reserves rate-limit quota. Only then does your handler touch any data.

  4. 4

    Keys retire, they don't vanish

    Revoking stamps a timestamp instead of deleting the row. The key stops working immediately, and the audit trail survives.

Engineering guarantees

What this does and does not promise

Safety boundary

The key shown in the demo is a fake and works nowhere. Real secrets are only created inside authenticated server commands, and this feature stays switched off behind a gate until it's certified for your setup.

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

Related capabilities

These capabilities share contracts and boundaries with this one.

Outbound webhooks

Send events your customers can trust, and replay the ones that fail.

Usage limits

One runaway user can't run up your bill.

Audit trail

A clean record of who did what, and when.

Build on the your customer api foundation

The docs describe the same contracts this page demonstrates.

Read the public docsSee all features