Keyring

Projects

One project per API you ship. Keys, policy and usage are scoped to it.

A project is one API of yours. Every key belongs to exactly one project, the SDK polls the policy of exactly one project, and usage is reported per project.

Projects → New project takes a name, a URL slug and optional default rate limits. Over the API:

curl -X POST https://keyring-api.belghalem.fr/v1/projects \
  -H "Authorization: Bearer $KEYRING_SECRET_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"name":"Orders API","slug":"orders-api"}'
{
  "object": "project",
  "id": "01a0...",
  "name": "Orders API",
  "slug": "orders-api",
  "policy_version": 1
}

The id is what your server sets as KEYRING_PROJECT_ID. One SDK instance serves one project; a process that serves two APIs constructs two instances.

Policy version

policy_version is the number the SDK's poller watches. Minting, editing, rotating or revoking any key in the project bumps it, and the next poll, at most 5 seconds later, fetches only what changed. Propagation explains the feed.

Default rate limits

A project's default_rate_limits apply to every key in it that does not set its own. The layering is resolved on the control plane, so a key with no limits of its own costs the SDK nothing extra. Changing a project default makes every node re-seed its whole policy set on its next poll. The shape of a rule is on the rate limits page.

Deleting a project

Deleting a project revokes every key beneath it in the same transaction, so every SDK node learns about it through the ordinary feed: there is no separate "project gone" signal to miss.

On this page