Skip to content

Managing keys

Partner API keys are managed by OpenBrix, not self-service. Keys are issued during onboarding and tied to your brand. This page describes the lifecycle so you know what to expect and when to ask for a change.

  1. Issued

    OpenBrix creates a key scoped to the services you’ve agreed. The full key (obxp_<prefix>_<secret>) is shown once and handed to you securely — store it in your secret manager immediately.

  2. In use

    Send it on every request (Authentication). Each successful call records last_used_at, which OpenBrix can use to spot unused or stale keys.

  3. Rotated

    If a key is compromised or on a routine schedule, it’s rotated — the same key record gets a new secret and the old secret stops working immediately. You receive the new key once. Swap it into your secret manager and redeploy.

  4. Revoked

    A revoked key is disabled (not deleted, so the audit trail survives) and every request with it returns 401 from that moment.

Rotation mints a new secret for a key and invalidates the old one immediately. Because only a hash of the secret is stored, a lost key is always rotated, never recovered. Rotation is performed by OpenBrix — contact your OpenBrix representative.

Administrative endpoints (OpenBrix operators)

Section titled “Administrative endpoints (OpenBrix operators)”

These are superuser-only and are not callable with a partner key — they’re listed for OpenBrix operators managing a brand’s keys. {id} is the brand id.

Method Path Purpose
POST /v2.0/brand/{id}/api-keys Issue a key (returns the plaintext once)
GET /v2.0/brand/{id}/api-keys List a brand’s keys (prefix + metadata, never the secret)
POST /v2.0/brand/{id}/api-keys/{keyId}/rotate Rotate a key’s secret
DELETE /v2.0/brand/{id}/api-keys/{keyId} Revoke a key

Contact OpenBrix to have it revoked immediately, and a replacement issued. Because the secret is only stored as a hash, OpenBrix cannot read your key back to you — a compromised key is always replaced, never recovered.