Tokens
Pionne project tokens are the keys the SDK uses to authenticate to /api/ingest.
Format
Section titled “Format”pio_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxpio_live_prefix (reserved for production tokens).- 48 random base62 characters (
a-zA-Z0-9). - Entropy: ~285 bits — brute-force resistant.
A project token has a strict write-only scope on /api/ingest. It cannot:
- List your events or issues.
- Modify your project.
- Access other projects.
- Read or modify your user account.
That’s why it’s safe to bundle the token in your app.
Server-side storage
Section titled “Server-side storage”Pionne never stores the token in plain text:
| Stored | Use |
|---|---|
| bcrypt hash (cost 10) | Verification on event login |
| First-12-chars lookup (indexed) | Fast lookup before bcrypt |
If someone gets a database dump, they cannot recover the original tokens.
Regeneration
Section titled “Regeneration”Two ways to regenerate:
From the mobile app
Section titled “From the mobile app”Settings → Project → Token → “Regenerate”. The new token is shown only once; the old one is invalidated instantly.
Via API
Section titled “Via API”curl -X POST https://api.pionne.app/projects/\{id\}/regenerate \ -H "Authorization: Bearer <user-token>"Response:
{ "token": "pio_live_yyyyyyyyyy..." }When to regenerate?
Section titled “When to regenerate?”- You committed your
.envto GitHub by mistake. - You suspect a leak (abnormal event spike on a Bundle ID you don’t recognize).
- A dev leaves the team.
- Periodic rotation (best practice: every 6-12 months).
Auth tokens (different)
Section titled “Auth tokens (different)”Not to be confused with the user auth tokens issued by Sanctum (cf. API Auth). These:
- Format:
<id>|<random>(e.g.2|abcXYZ...). - Scope: read/write on your entire account.
- Used by: the Pionne mobile app, the upload-sourcemaps CLI, your CI scripts.
- Never to be bundled in an app.
Best practices
Section titled “Best practices”- Project tokens → in
.env+EXPO_PUBLIC_PIONNE_TOKEN, safe to bundle. - User auth tokens → in EAS Secrets / GitHub Secrets, never bundled.
- Enable Bundle ID pinning (auto, nothing to do) to limit the impact of a leak.
If a token leaks anyway
Section titled “If a token leaks anyway”Three lines of defense in place, in order:
- Bundle ID pinning (details) — an attacker reusing your token from their own app gets
403. Their events don’t pollute your dashboard. - Server rate limit (details) — per-token cap. Even if the attacker matches your bundle (rare case: advanced reverse-engineering), the server quickly blocks them with
429s. - Token regeneration — immediate invalidation. Re-deploy your app with the new token.