API overview & authentication

The error.page HTTP API lets any application — a backend service, a mobile or desktop app, a CLI tool, a scheduled job, an embedded device — report errors and read its data over plain HTTPS. There is no SDK to install and no language requirement: if you can make an HTTPS request, you can integrate.

This page covers the fundamentals — base URL, versioning, authentication, limits and errors. Then:

• Report errors from any app — send an error with logs, screenshots and core/crash dumps.
• Read errors, status & releases — pull your stream and mark releases.

Base URL & versioning

https://error.page/api

The current version is v2, carried in the path (/api/v2/…). We add fields without bumping the version; a breaking change ships as a new version prefix, and the previous one keeps working during a deprecation window announced in advance. Always send requests over HTTPS (TLS 1.2+) — plaintext HTTP is redirected and must not be used to carry keys.

Authentication

Every request identifies a project with its API key, sent in the X-Project-Key header. Beyond that, error.page supports three trust tiers so you can start simple and harden as you grow. Pick the strongest one your environment allows.

Tier	How you authenticate	Use it for
Public key	X-Project-Key: <api_key> only	Browser/SDK reporting where the key is necessarily public.
Secret key	X-Project-Key and X-Secret-Key: <secret_key>	Server-to-server reporting from code your users can't read. Required for all read/release endpoints.
Signed token	X-Project-Key and Authorization: Bearer <JWT>	High-assurance ingest: your backend mints a short-lived HMAC-signed token so forged reports can't be trusted. See Hardened ingest.

Keys live on your project's Projects & API keys page and can be rotated at any time; see Projects & API keys.

For non-web apps, always use the secret key (or a signed token). The public API key is designed to ship in browser code, so it isn't a secret — send X-Secret-Key from any server, mobile backend, or desktop/CLI context where you control the binary.

Turn on Require X-Secret-Key on ingest for a project (Projects → Security) to reject any report that doesn't present the secret. That makes the public key alone useless for writing.

Request & response format

• Reading / JSON writes: send Content-Type: application/json and a JSON body; responses are JSON.
• Uploading files (screenshots, logs, core dumps): send multipart/form-data. Scalar fields become form fields; files are file parts. See the Ingest API for full examples.
• All responses are UTF-8 JSON. Success is 200/201; failures carry an error string and, where useful, extra context (e.g. limit, used, limit_bytes).

Rate limits

The public API key ships in client code, so rate limits — not the key — are what bound abuse. Two dimensions are enforced together (per minute):

Scope	Free	Paid
Per project	1,000	6,000
Per project + client IP	120	300
Unauthenticated / unknown key, per IP	60	60

Exceeding a limit returns 429 Too Many Requests with a Retry-After header. Legitimate distributed traffic (many users, many IPs) flows up to the per-project ceiling; a single abusive origin is capped far lower. Back off and retry with jitter on 429.

Monthly quotas

Separately from rate limits, each account has a monthly error allowance metered against your billing period:

Plan	Errors / month	Attachments	Max per-report size
Free	500	— (text only)	3 KB
Pro	50,000	✓	1 MB
Business	500,000	✓	2 MB
Enterprise	Unlimited	✓	Unlimited

When the allowance is exhausted, ingest returns 429 with { "limit": …, "used": … }. Usage is account-wide (summed across the account's projects) and resets at the start of each billing period. See Plans & billing.

Error codes

Status	Meaning	Typical fix
201	Event ingested.	—
200	Read/action succeeded.	—
401	Missing/invalid X-Project-Key, or a required X-Secret-Key / signed token was absent or wrong.	Check the header names and values; secrets are compared in constant time.
403	The endpoint needs a plan you're not on (e.g. releases are Business).	Upgrade, or use a different endpoint.
404	Unknown project slug.	Verify the slug.
413	Attachments on a text-only (Free) plan, or the report exceeds your plan's per-report size cap.	Upgrade, or drop/shrink attachments.
422	Validation failed, or a disallowed attachment type.	Fix the field or file type.
429	Rate limit or monthly quota exceeded.	Honour Retry-After (rate limit) or upgrade/wait for reset (quota).
5xx	Transient server error.	Retry with exponential backoff.

Idempotency & deduplication

error.page fingerprints each incoming error (from its type, message and endpoint) and groups repeated occurrences into a single incident — so sending the same error a thousand times produces one incident with a count of 1,000, not a thousand incidents. See Incident feed.

There is no client-supplied idempotency key: each successful POST /ingest is recorded as one occurrence and counts once against your monthly quota. If your transport might retry, only retry on network errors or 5xx — never on a 201 (it succeeded) or a 4xx (it won't).

Machine-readable spec (OpenAPI)

An OpenAPI 3.1 description of every endpoint on this page is published at:

https://error.page/openapi.yaml

Point Postman, Insomnia, openapi-generator, or your own tooling at it to generate a typed client in your language. It's versioned alongside the API.

Data handling

• Reports are transmitted over TLS and stored encrypted at rest. Secrets (secret keys, signing secrets, integration tokens) are stored encrypted and never returned in read responses.
• The read API returns a safe projection only — it never exposes per-visitor session fingerprints or captured lead/engagement data.
• If you send end-user "replay" breadcrumbs in metadata, they pass through PII redaction before storage. Still, treat error payloads as potentially sensitive and avoid sending secrets, tokens or raw personal data in message/metadata.

Need higher limits, a custom data-processing agreement, or a private ingest region? See your SLA or contact sales.