Overview
Object-first HTTP API: ingest (DSN), Issues, Events, and session auth.
Same binary, two credentials. Default base: http://localhost:8080 (EPURE_PUBLIC_URL if you changed the port). Health (no auth): GET /health → { "status": "ok" }.
How is the HTTP API split?
Ingest uses a DSN; Issues and Events use a session cookie. Ingest success is 202 Accepted with { "id": "<uuid>" }.
| Object | Auth | Job |
|---|---|---|
| Ingest | DSN | Envelope, store, release files, user feedback |
| Issues | Session | List, patch, merge, snooze, bulk |
| Events | Session | Occurrences, timeline, crash-dialog feedback |
| Authentication | reference | Which header where |
| Errors | reference | Codes and what to do next |
Body limit is 2 MB. DSN headers on /api/v1/* return 401; a session cookie on envelope or store does nothing.
Surfaces
FAQ
Is a DSN the same as a session cookie?
No. The DSN authenticates ingest: envelope, store, release files, user feedback. Issues and Events need a login cookie. Mixing them fails, with DSN on /api/v1/* returning 401 and a cookie on ingest ignored. See Authentication.
What does HTTP 202 mean?
The DSN and body passed the gate. Persist and JS/TS demangle run after the response on a Tokio queue. A 202 can still pair with an empty Issues list when the environment filter is wrong. See Verify.
What is the 2 MB cap?
Ingest bodies over 2 MB return 413 payload_too_large. The spike valve (~100/min/fingerprint) still returns 202 and may drop bodies. The hourly project cap (default 5000) returns 403. Full tables: Errors.