Sentry: 403 from the ingest endpoint

Sentry: 403 from the ingest endpoint

The error

SDK debug logs show the envelope POST returning 403. Events are refused at the door.

Causes, in order of likelihood

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.

Confirmation

Copy the DSN from the failing environment and compare it, segment by segment, with Settings > Projects > Client Keys (DSN) in the org you expect. Then send one event with debug: true and read the exact URL the SDK posts to.

Fix and verify

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.

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.