API keys & secrets
A live integration uses two independent credentials, one per trust direction. Keep them separate — they protect opposite flows.
Inbound API key (you → LootBox Solutions)
Provisioned in Admin → Integration → API keys. Each key has:
- A public key id (
igk_…) — sent in theX-Key-Idheader. Visible on the key’s row. - A secret — shown exactly once at creation. Store it in your secret manager immediately; it is never displayed again.
You sign every S2S request with this secret. See Authentication for the envelope.
- Keys can be revoked at any time; a revoked key fails closed with
INVALID_SIGNATURE. - Rotate by creating a new key, deploying it, then revoking the old one.
- Secrets are stored hashed — a database leak does not expose a usable secret.
Outbound secret (LootBox Solutions → you)
A single shared secret, set in Integration → Settings (stored encrypted). LootBox Solutions signs every wallet RPC call it makes to you with this secret, using the same HMAC envelope.
Webhooks are signed differently: each webhook endpoint has its own signing secret, shown with Reveal in Integration → Webhooks. Verify a webhook with the secret of the endpoint that received it.
Verify it on your endpoints to be sure a request really came from LootBox Solutions.
Outbound calls carry X-Timestamp and X-Signature (but no X-Key-Id —
there is a single outbound secret, not a keyring).
Why two credentials
The inbound key authenticates you to us; the outbound secret and the webhook signing secrets authenticate us to you. Compromise of one does not compromise the others, and each can be rotated independently. A single client implementation can serve both directions because the signing envelope is identical.