Read errors, status, releases & source maps

Beyond reporting errors, the API lets your systems read your error stream and project health, tell error.page when a release ships (to auto-resolve incidents and notify affected users), and upload source maps so minified or native stack traces resolve to your original code. See API overview & authentication for base URL and keys.

All of these are server-to-server and require the secret key (X-Secret-Key) — the public API key is never enough to read private data.

Read error events

GET https://error.page/api/v2/events

Headers: X-Project-Key and X-Secret-Key. Returns up to the 200 most recent events from the last 7 days, newest first, plus a total count. The response is a safe projection — it never includes per-visitor fingerprints or captured lead/engagement data.

curl -sS https://error.page/api/v2/events \
  -H "X-Project-Key: $ERRORPAGE_KEY" \
  -H "X-Secret-Key: $ERRORPAGE_SECRET"

{
  "events": [
    {
      "id": 12345,
      "error_type": "server_error",
      "message": "Timeout calling payments provider",
      "status": "active",
      "severity": "high",
      "affected_users": 12,
      "metadata": { "host": "api-prod-3", "env": "production" },
      "occurred_at": "2026-07-25T15:04:01+00:00"
    }
  ],
  "total": 4821
}

severity is present only when AI analysis is enabled. Poll this endpoint on a sensible interval (it's rate-limited like ingest) or, for push delivery, use webhooks instead — they notify you on error.created, acknowledgements and resolutions without polling.

Project status (health check)

GET https://error.page/api/v2/projects/{slug}/status

Public (no secret required) — safe to call from a status page or uptime probe. Reports whether the project is currently healthy or degraded, plus the incident pipeline state.

{
  "status": "degraded",
  "incident_status": "acknowledged",
  "acknowledged": true,
  "last_error_at": "2026-07-25T15:04:01+00:00"
}

Mark a release (auto-resolve & notify)

POST https://error.page/api/v2/releases

Business plan. Headers: X-Project-Key + X-Secret-Key, Content-Type: application/json. Call this from CI when a build reaches production. Incidents linked to the issues you name — or named directly by fingerprint — are marked resolved, and any users who opted in during the outage are notified that it's fixed.

Field	Type	Notes
version	string	The release/build identifier (≤ 120).
issues[]	string[]	Issue references fixed in this release (e.g. PROJ-481, #204). Up to 500.
incident_group_ids[]	string[]	Resolve incidents directly by fingerprint. Up to 500.

curl -sS https://error.page/api/v2/releases \
  -H "X-Project-Key: $ERRORPAGE_KEY" \
  -H "X-Secret-Key: $ERRORPAGE_SECRET" \
  -H "Content-Type: application/json" \
  -d '{ "version": "api@2026.7.4", "issues": ["PROJ-481", "PROJ-490"] }'

{ "message": "Release processed.", "version": "api@2026.7.4",
  "incidents_resolved": 2, "users_notified": 37 }

See GitHub & Jira integrations to link incidents to issues automatically.

Upload source maps

POST https://error.page/api/v2/sourcemaps

Business plan. Headers: X-Project-Key + X-Secret-Key; body is multipart/form-data. Upload the source maps for a release so minified production stack traces symbolicate back to your original source. Upload as part of the same CI step that publishes the release, keyed by the same release value you send on ingest.

Field	Type	Required	Notes
release	string	✓	Must match the release on your error reports (≤ 120).
bundle	string	—	Bundle name for a single-file upload (≤ 255).
file	file	—	A single .map (≤ 50 MB).
maps[]	file[]	—	Multiple .map files in one call (up to 100; ≤ 50 MB each).

Provide file or maps[] (at least one). Each file must look like a source map (a .map, or JSON containing a mappings field) or it's rejected.

curl -sS https://error.page/api/v2/sourcemaps \
  -H "X-Project-Key: $ERRORPAGE_KEY" \
  -H "X-Secret-Key: $ERRORPAGE_SECRET" \
  -F "release=web@2026.7.4" \
  -F "maps[]=@dist/app.js.map" \
  -F "maps[]=@dist/vendor.js.map"

{ "message": "Source maps stored.", "release": "web@2026.7.4", "count": 2 }

See Source maps for how symbolication is applied and retention details.

Putting it together in CI

A typical deploy step, once the build is live:

# 1. Upload source maps for this release
curl -fsS https://error.page/api/v2/sourcemaps \
  -H "X-Project-Key: $ERRORPAGE_KEY" -H "X-Secret-Key: $ERRORPAGE_SECRET" \
  -F "release=$VERSION" -F "maps[]=@dist/app.js.map"

# 2. Mark the release so fixed incidents resolve and users get notified
curl -fsS https://error.page/api/v2/releases \
  -H "X-Project-Key: $ERRORPAGE_KEY" -H "X-Secret-Key: $ERRORPAGE_SECRET" \
  -H "Content-Type: application/json" \
  -d "{\"version\":\"$VERSION\",\"issues\":$FIXED_ISSUES_JSON}"

Keep $ERRORPAGE_SECRET in your CI secret store, never in the repo.