Reporting-Endpoints
The HTTP Reporting-Endpoints response header declares named endpoints where the browser sends reports for CSP violations, deprecation warnings, intervention notices, and crash logs.
Usage
The Reporting-Endpoints header is part of the W3C Reporting API and serves as the successor to Report-To. Where Report-To uses JSON objects with nested arrays, Reporting-Endpoints is defined as a Structured Fields Dictionary with a simpler key-value syntax.
A server includes one or more named endpoints in
the header value. Each endpoint is a key paired
with a quoted URL. Other headers reference these
endpoint names to route specific report types. For
example, a
Content-Security-Policy
header uses the report-to directive with the
endpoint name to direct violation reports to the
declared URL.
Reports are sent out-of-band by the browser in the background. The endpoint URLs must be HTTPS. The browser silently discards endpoints with non-secure URLs.
Directives
endpoint-name
The endpoint-name is a token identifying the
reporting destination. The name is referenced by
other HTTP headers such as
Content-Security-Policy or Cross-Origin-Opener-Policy
to route their reports. The value paired with the
name is a quoted URL pointing to the collection
endpoint.
Multiple endpoints are separated by commas, each with its own name and URL.
Example
A single endpoint named default collects all
report types not routed to a specific named
endpoint. The browser sends deprecation warnings,
intervention notices, and crash reports to this URL
automatically.
Reporting-Endpoints: default="https://reports.example.re/default"
A CSP violation endpoint named csp-endpoint
receives Content-Security-Policy violation reports.
The matching Content-Security-Policy header ties
violations to this endpoint through its report-to
directive.
Reporting-Endpoints: csp-endpoint="https://reports.example.re/csp"
Content-Security-Policy: default-src 'self'; report-to csp-endpoint
Multiple endpoints in a single header cover
different report categories. The coop_report
endpoint handles Cross-Origin-Opener-Policy
violations while permissions_policy handles
Permissions-Policy violations. A default endpoint
catches everything else.
Reporting-Endpoints: coop_report="https://reports.example.re/coop", default="https://reports.example.re/browser-errors", permissions_policy="https://reports.example.re/permissions"
Which reports go where
Each report type picks its endpoint through its own
policy header rather than through this one.
CSP violations follow the
report-to directive inside the policy,
COEP and
COOP violations follow
the report-to parameter on their headers, and
Reporting-Endpoints only resolves the names those
policies use into URLs. Deprecation and intervention
reports have no policy header of their own and fall
back to the endpoint named default, as do crash
reports where no crash-reporting endpoint exists.
Endpoints accept HTTPS URLs alone, and delivery
arrives as batched POST requests carrying
application/reports+json with a JSON array inside.
The age field counts milliseconds since the report
was generated rather than carrying a timestamp,
which is deliberate, keeping client clock detail out
of the payload. An endpoint answering 410 asks
the browser to stop delivering entirely.
Delivery is explicitly best-effort. The specification rules out treating reports as a reliable channel, so gaps in a reporting dashboard mean little on their own.
The header ships across Chromium-based browsers,
Firefox, and Safari, with the default endpoint
name unsupported in Safari, so deprecation and
intervention reporting stays out of reach there.
Network Error Logging never moved over and
still requires the older Report-To
header, which is the one reason production configs
carry both.
