Authentication
API keys for backends, JWTs for the dashboard, and how team keys resolve.
Reput.io accepts two forms of authentication on the same endpoints. Pick whichever fits your use case — you never need both on the same request.
API keys
API keys are the normal way to call the API from a backend, SIEM, or script.
- Format:
rpt_+ 64 hex characters (e.g.rpt_a1b2c3d4e5f6…) - Header:
X-Api-Key: rpt_… - Lifetime: never expire; you revoke them manually
- Storage: we hash the key before storing it, so even we can't recover a lost one — you'll need to mint a new one
Create and revoke
Both actions live on the dashboard. Click New Key, give it a name ("Production SIEM", "Alice — staging"), and copy the full value from the banner that appears once. Revoking is a single click.
How many keys can I have?
| Plan | Keys per account |
|---|---|
| Free | 1 |
| Starter | 2 |
| Pro | 5 |
| Team | 15 |
| Enterprise | Custom |
Team members each have their own key quota (see Teams).
JWT tokens (web dashboard only)
When you log in through the web UI, the backend issues:
- An access token (1h TTL) — used as
Authorization: Bearer <token>on dashboard requests - A refresh token (30d TTL) — used to mint a fresh access token without re-login
You don't need to deal with JWTs directly unless you're building a non-standard client against our web endpoints (/web/lookup, /stats, /api-keys, /audit/log, /team/…). External integrations should use API keys.
Team members and key resolution
If you're a viewer in someone else's Team workspace, your API keys behave a little differently:
- They're personal — listed under your dashboard, not the owner's
- On every validated request, we resolve them to the workspace owner
- Quota, rate limits, and feature access come from the owner's plan
- Usage is still attributed to you (for per-member breakdowns)
When the owner removes you from the team, your keys keep working — they just revert to consuming your own plan's Free quota (500 queries/day) instead of the team pool. No manual rotation needed. See Teams for the full model.
Rotating a key safely
- Mint a new key first (
New Keyon the dashboard) - Update your service/SIEM to use the new key
- Verify traffic is flowing on the new key (last_used_at updates on the dashboard)
- Revoke the old key
Because keys don't expire, there's no rush — but don't skip step 3 unless you enjoy 2am pages.
Security checklist
- Store keys in a secrets manager (AWS Secrets Manager, HashiCorp Vault, Doppler), not in
.envfiles committed to git - Use a distinct key per service so revocation is surgical
- Rotate keys when a team member leaves or when a host running your integration is decommissioned
- Don't share a single key between humans — each analyst should have their own so audit logs and per-key usage are meaningful