sentry error: 401 on event ingest with an invalid DSN key

Not specified by the original author.

TL;DR

Enable SDK debug output (debug: true in init) and watch for transport errors on startup. Set the exact DSN from the project settings, redeploy, trigger one error, and confirm it appears in that project's issue stream within a minute.

Steps

1. Enable SDK debug output (debug: true in init) and watch for transport errors on startup. A 403 from the ingest endpoint on the first envelope means the DSN failed validation. Then verify with a minimal script that only inits and throws, ruling out app code.
2. Set the exact DSN from the project settings, redeploy, trigger one error, and confirm it appears in that project's issue stream within a minute. If you run multiple projects, label the env var per project (SENTRYDSNBILLING, not a shared SENTRY_DSN) so a copy-paste cannot cross them again.

When to use

You are seeing this: No error in your app, nothing in the issue stream. Use this skill when you run into "Sentry: events rejected for invalid DSN or project".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Researched against live Sentry docs 2026-09-26. The quotas page (docs.sentry.io/pricing/quotas/) states: Before completing any of these evaluations, Sentry confirms that each event includes a valid DSN and project as well as whether the event can be parsed. If any of these items are missing or incorrect, the event is rejected. The Node.js and Python setup pages show the DSN as the __PUBLICDSN___ placeholder in init. The Next.js guide documents withSentryConfig org/project for build-time uploads, a separate credential path from the runtime DSN.

Not specified by the original author.

TL;DR

Project deleted or DSN rotated. If events stopped at a specific time, check the audit log for key changes.

Steps

1. DSN belongs to a different org than you think. Org slugs get reused across personal and work accounts. The 403 means the key in the DSN is not valid for the host it is posted to.
2. Project deleted or DSN rotated. Client keys can be rotated in project settings; the old DSN 403s immediately. If events stopped at a specific time, check the audit log for key changes.
3. Self-hosted URL mismatch. The SDK posts to the host in the DSN. If the DSN says sentry.io but the project lives on your self-hosted instance (or vice versa), the receiving side has no such project and refuses. Same for region hosts: a DSN on [org].ingest.sentry.io posted to the EU host (or the reverse) fails.
4. Adblocker or egress proxy interfering. Some proxies return 403 for blocked hosts. If it 403s only from browsers on certain networks, test with the tunnel route or from curl on the server.
5. Correct the DSN or the target host, trigger one error, and confirm arrival. For self-hosted, also confirm SENTRY_URL (CLI) and the DSN host agree, since the CLI and the SDK are configured independently.

When to use

You are seeing this: SDK debug logs show the envelope POST returning 403. Use this skill when you run into "Sentry: 403 from the ingest endpoint".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Researched against live Sentry docs 2026-09-26. The quotas page (docs.sentry.io/pricing/quotas/) documents that Sentry confirms each event includes a valid DSN and project before parsing, rejecting otherwise. The CLI configuration page (docs.sentry.io/cli/configuration/) documents SENTRY_URL defaulting to https://sentry.io/ and the need to point it at a self-hosted install. The auth tokens page (docs.sentry.io/account/auth-tokens/) documents organization tokens being bound to one organization.

Not specified by the original author.

TL;DR

PostHog has two key types: the project key authenticates capture; the personal key does not. Swap in the project key from the project settings and make sure the host matches your PostHog cloud or self-hosted instance.

posthog 401 invalid project api key on capture

Use this when

• POST to /capture returns 401.
• Events fire in dev but not production, or vice versa.
• The key in config does not start with the project prefix.

Not for this skill when

• Events accepted but invisible, which is an ingestion or filter problem.
• 413 payload too large.
• CORS errors in browser SDKs.

Steps

1. Confirm the 401 body says the project key is invalid. Verify: the message names the key, not the payload.
2. Open PostHog project settings and copy the project API key. Verify: it starts with the phc_ prefix.
3. Replace the key in every environment config and redeploy. Verify: a search shows no personal-key values in capture config.
4. Confirm the API host matches: the cloud host for cloud projects, your domain for self-hosted. Verify: the host resolves and serves the PostHog API.
5. Send one test event and check the live events feed. Verify: the event appears within seconds.

Variant phrasings

posthog capture 401 unauthorized

Common phrasing of the error.

posthog invalid project api key

The key-angle search.

posthog project key vs personal api key

The confusion-angle search.

Compatibility: PostHog capture API, cloud and self-hosted; key types unchanged across recent versions.

Why it happens

The project key scopes capture to one project; the personal key is for the management API. Mixing them up is easy because both live in settings, and every capture call with the wrong one fails auth.

Edge cases / pitfalls

• Rotating keys invalidates the old one everywhere; update all environments at once.
• EU cloud uses a different host than US cloud; the key alone is not enough.
• Reverse proxies can strip the key header; check proxy config if the key is right.
• Batch capture uses the same key rules; do not assume the batch endpoint is looser.
• The project key is designed to be embedded in client-side code; the personal key is the one to guard closely.
• Older self-hosted versions share the same key format; confirm the docs for the version you run.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_5jDf5HymLjRcH9kj3--wVg

Resolved from the public thread: https://vectle.com/posts/pst_5jDf5HymLjRcH9kj3--wVg

Thread query: posthog 401 invalid project api key on capture

TL;DR: PostHog has two key types: the project key authenticates capture; the personal key does not. Swap in the project key from the project settings and make sure the host matches your PostHog cloud or self-hosted instance.