SP Cambo
All documentation

Authentication

One credential type for inference, scoped per key, revocable at any time, with an explicit authenticated re-copy flow for your own keys.

Two credential types, kept apart

Signing in to this website creates a browser session. That session can manage your account, but it cannot call a model.

Calling a model requires an SP Cambo API key. A key cannot manage your account, cannot buy packages and cannot read your other keys. Losing one is bad, but it is not the same as losing your login.

Sending the key

Use the header your client already uses. Both are accepted on the inference gateway.

bash
# Anthropic-compatible clients
curl https://sp-cambo.store/v1/messages \
  -H "x-api-key: sk-your-key"

# OpenAI-compatible clients
curl https://sp-cambo.store/v1/responses \
  -H "Authorization: Bearer sk-your-key"

Never put a key in a query string. Query strings end up in proxy logs, browser history and error reports.

Re-copying your own key

Normal key lists are always masked. For customer-owned inference keys, SP Cambo stores a lookup hash for authentication plus an encrypted recovery copy. From API keys, choose Copy key to explicitly retrieve the current secret through your authenticated session. The reveal request is throttled and audited.

Do not treat this as ordinary display data: use it only on a trusted device and keep the secret in an environment variable or secret manager. Rotate the key if you believe the secret or your account session was exposed; rotation invalidates the previous secret immediately.

Keys created before secure recovery support cannot be reconstructed from their old hash. Rotate one of those legacy keys once; the new secret becomes re-copyable from then on.

Scope every key

A key can be restricted to specific model aliases. Give each environment its own key, scoped to what that environment actually needs:

  • a laptop key for interactive CLI work;
  • a CI key, scoped narrowly, stored as a masked secret in your pipeline;
  • a production key that nobody copies onto a developer machine.

When you revoke one, the others keep working. That is the whole point.

Key states

  • Active — usable.
  • Disabled — temporarily refused; can be re-enabled.
  • Revoked — permanently dead. This cannot be undone.
  • Expired — past its expiry date, if you set one.

A revoked or expired key fails immediately and does not consume any balance.

Testing a key without spending

The dashboard can validate a key and report its status, scope and remaining balance without running an inference request. Use that instead of firing a throwaway prompt: validation does not reserve or spend any of your quota.

If a key leaks

  1. Revoke it. Do this first, before investigating — revocation is instant.
  2. Create a replacement with the narrowest scope that still works.
  3. Check usage and activity for requests you do not recognise. Activity is recorded per key.
  4. Purge the key from wherever it leaked: shell history, committed files, CI logs, screenshots. Rotating is not enough if the old value is still in your git history.

Storing keys safely

  • Read keys from environment variables or a secret manager, never from source.
  • Keep them out of client-side code entirely. A key shipped to a browser or a mobile app is a public key, whatever your intentions.
  • Do not paste keys into chat tools, issue trackers or AI assistants.
  • Treat any key that has ever been committed as compromised, even in a private repository, and rotate it.