Invalid API key: find the bad key in minutes
The SDK rejects your key, ingest returns auth errors, or events silently vanish. The fix is almost always one of four key-handling mistakes.
What this looks like
Authentication failures with AllStak show up in two ways: an explicit auth error in your application logs when the SDK sends, or — more often — events that simply never arrive because the ingest endpoint rejected them. Both trace back to the API key your app presented.
AllStak API keys look like ask_live_… and are copied per-project from the dashboard. Anything that mutates, truncates, or swaps that string — quoting mistakes, stray whitespace, the wrong project's key, or a key that was rotated after you deployed — produces the same symptom.
Common root causes
The wrong project's key
Keys are scoped per project. Copying the key from a different project in the same organization authenticates fine for that project — your events just appear there, or fail if it was revoked.
Whitespace or quotes in the env var
A trailing newline from copy-paste, surrounding quotes baked into the value (ALLSTAK_API_KEY="ask_live_…" in some env file formats), or a leading space all make the key invalid byte-for-byte.
Key missing in the runtime environment
Frameworks split build-time and runtime variables — in Next.js, browser code only sees NEXT_PUBLIC_* variables inlined at build time, while server code reads process.env at runtime. A key set in one place but needed in the other arrives as undefined.
Revoked or rotated key
If the key was rotated in the dashboard, every deploy still holding the old value starts failing auth from that moment — often noticed days later as a sudden stop in events.
Step-by-step diagnosis
Work from the dashboard outward: first the key itself, then how it travels into your process.
- 1
Copy the key fresh from project settings
Open the correct project in the AllStak dashboard and copy its key again. Confirm it starts with ask_live_ and that you are in the project you expect events to appear in — not a sibling project.
- 2
Inspect the value for whitespace and quotes
Print the key's length and first/last characters in a debug log (never the full key). A length that is off by one or two, or a key that starts with a quote character, pinpoints copy-paste damage immediately.
- 3
Verify the variable exists at runtime
Log whether the variable is set when the SDK initializes — in the same process and context that runs in production. Remember build-time vs runtime splits: a browser bundle needs the key inlined at build (e.g. VITE_ALLSTAK_API_KEY, NEXT_PUBLIC_*), a server reads it at startup.
- 4
Check whether the key was rotated
Compare the deployed key against the current one in project settings. If they differ, someone rotated it — update your secrets store and redeploy every service that uses it.
- 5
Redeploy and confirm with a test event
After fixing the value, redeploy (env vars are read at process start) and trigger one test error. If it appears in the right project, the key path is healthy end to end.
Prevent it from recurring
- Keep the key in a secrets manager or CI variable — one source of truth per environment.
- Never commit keys to source control; use .env files locally and platform secrets in deploys.
- When rotating a key, update every deployment that uses it in the same change window.
- Add a startup log line confirming the key variable is present (presence only, never the value).
Still stuck?
If the key matches project settings exactly and auth still fails, check the AllStak status page, then email [email protected] with your project name and the approximate time of the failures (never send the key itself) — we can check what ingest saw.
Frequently asked questions
What does an AllStak API key look like?
Keys start with ask_live_ and are copied per project from the AllStak dashboard. Each project has its own key; events authenticate and route to the project that owns the key.
Why does the key work locally but fail in production?
Almost always an environment-variable gap: the value lives in your local .env but was never added to the production deploy, or your framework needed it at build time (e.g. NEXT_PUBLIC_* / VITE_*) and the build ran without it.
Is it safe to expose the key in browser code?
Browser SDKs necessarily ship the ingest key to the client — it only allows sending events to your project, not reading data. Keep it in environment variables anyway so rotation stays a config change, not a code change.
What happens to events sent with an old rotated key?
They are rejected at the ingest endpoint and are not recoverable. Update the key everywhere and redeploy promptly after a rotation.
One key, one platform
Copy your project key, drop it in an environment variable, and your errors, logs, and traces start flowing. Start free.