Skip to main content
Robase uses bearer API keys. Pass your key in the Authorization header on every request: 
Authorization: Bearer rb_live_7f3a...

​
Key formats

Every key has the format rb_<env>_<32-char-token>. The <env> segment tells you at a glance what the key does:
PrefixModeBehavior
rb_live_*LiveReal carriers, real money, real delivery receipts.
rb_test_*TestSimulator: magic numbers produce deterministic outcomes. Does not debit your wallet.
Keep separate keys per environment. Never ship a rb_live_ key inside a mobile app or browser bundle — test keys are safe to expose in CI-only test suites.

​
Permission scopes

When you create a key you pick its permission:
​
permission
string
required
One of:
  • full — all endpoints (default). Sends + reads + admin (templates, sender IDs, webhooks, domains).
  • sending — POST /v1/sms, POST /v1/emails, POST /v1/sms/batch, POST /v1/emails/batch only. Read operations fail with permission_error.
Use sending keys for servers that only emit messages — no dashboard, no template management. If that key leaks you minimize the blast radius.

​
Revoking keys

Keys are revoked instantly from the dashboard (API keys → Revoke). Revoked keys return 401 authentication_error on the next request. We hash keys with argon2id + a server-side pepper, so even a database dump doesn’t hand an attacker your secrets. But revocation is still the fastest remediation if you think a key leaked.

​
Session authentication (dashboard only)

Dashboard endpoints (/dashboard/*) use a session cookie set by /auth/login — not an API key. You rarely need this unless you’re embedding the dashboard somewhere custom.

​
Idempotency + replay

Auth has nothing to do with idempotency — see Idempotency for how we de-duplicate retries. The two concepts are orthogonal: a retried request with the same Idempotency-Key still needs a valid API key.