Skip to content
tlyfePro Partner API

Authentication

Key format

Section titled “Key format”

A partner API key looks like this:

obxp_bc7bffa51b91_b9c56e89330d2f9f58ce41e39380966a7087164e6ac93844de9197f4b764eba9
│    │            │
│    │            └─ secret  (64 hex chars) — high-entropy, shown to you once
│    └────────────── prefix  (12 hex chars) — non-secret, used for lookup
└─────────────────── namespace, always "obxp"
  • The prefix is stored in the clear and identifies the key.
  • The secret is never stored — only a SHA-256 hash of it is kept. If you lose the key, it cannot be recovered; rotate to get a new one.

Sending the key

Section titled “Sending the key”

Send the key on every request, by either header:

Terminal window
curl https://wl.api.cluster.openbrix.co.uk/v2.0/properties/portal/leads \
  -H "Authorization: Bearer obxp_<prefix>_<secret>"

If both are present, X-API-Key takes precedence.

What verification checks

Section titled “What verification checks”

On each request the key is checked, in order. Any failure returns 401 with {"status": false, "message": "Invalid API key."}:

Check Fails when
Format not obxp_<prefix>_<secret>
Exists no key with that prefix
Active the key was revoked (is_active = false)
Not expired expires_at is in the past
Secret matches the secret’s SHA-256 doesn’t match the stored hash (constant-time compared)

A missing key returns 401 with {"status": false, "message": "No API key provided."}.

Once verified, the key resolves to your brand and its scopes; the request then passes through the scope and entitlement gates. Successful use updates the key’s last_used_at timestamp.