Key format
Every ByteSpike key starts withsk-byts-. You generate them in
Console → API keys; the
secret value is shown once at creation time, then masked. To
retrieve a plaintext later, use the per-key reveal flow in the console
or GET /v1/keys/{id}/reveal on the management API.
Header layout per protocol
ByteSpike accepts the native auth header for whichever protocol you’re calling. The same key works across all three — pick the header your client speaks.
You can also send
Authorization: Bearer on the Anthropic endpoint
and x-api-key on the OpenAI endpoint — the gateway accepts both
shapes on both routes. If both headers are present, x-api-key wins.
The gateway never reads request bodies to discover credentials.
Per-key controls
Each key carries its own configuration, set when you create the key and editable later from the console:
A key is bound to exactly one routing group — there is no
multi-group binding today. If you need a single client to reach
multiple groups (e.g. Claude + DeepSeek), create separate keys per
group and select per request, or call models that have cross-group
fallback configured.
Key lifecycle
Create
GET /v1/keys return a masked
form (sk-byts-...****1234).
Rotate
POST /v1/keys/{id}/rotate re-rolls the secret in place. The old
secret stops working immediately on rotation — there’s no
overlap window. Plan deploys accordingly: roll your config + verify
on the new secret before invoking rotate, or use two keys with
staggered rotations.
Reveal
GET /v1/keys/{id}/reveal returns the plaintext for a key you
already have access to. Useful for recovery flows where the operator
has lost their copy but is still authenticated.
Delete
DELETE /v1/keys/{id} — immediate, no undo. Pending requests using
that key in-flight get a 401 mid-stream.
Failure modes
The error envelope matches the protocol you called. Anthropic shape:
None of these are billed — failures don’t consume credits.
Programmatic key management
The full management surface lives under/api/v1/keys. Cookie auth
(from the console) and x-api-key auth (with any active key) both
work.
Test a key before shipping
Console → Models has a Test button next to every model. The console picks the right key from your set automatically — the one whosegroup_id actually
matches the model. A 200 there confirms key + group + model all
line up before you commit to wiring it into a client.
You can also dial test from the API: