Read errors, status & releases

Beyond reporting errors, the API lets your systems read your error stream and project health, and tell error.page when a release ships (to auto-resolve incidents and notify affected users). 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.

Putting it together in CI

A typical deploy step, once the build is live:

# 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.