Choose an endpoint
Where browser reports go, the HTTPS requirement, named vs the default endpoint, and whether to build a collector or use a hosted one.
Last update:
A reporting endpoint is just a URL that accepts the browser's POST. The choices
that matter are how you name endpoints, the HTTPS requirement, and whether you run
the collector yourself.
The rules
A few rules govern every endpoint. The URL must be HTTPS, the browser silently
ignores a non-secure one, so an http:// URL or a typo means reports vanish with no
error. You can declare several named endpoints in one header and route different
policies to different URLs. And reports that have no explicit target, deprecations,
interventions, and crashes, go to an endpoint named default; if you do not declare
one, those report types are dropped.
Reporting-Endpoints:
default="https://<Endpoint-ID>.report.centralcsp.com",
csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"See the full syntax on the Reporting-Endpoints reference.
Build or buy
Receiving the POST is the easy part. The work is everything after: real traffic
sends a high volume of reports, much of it duplicate noise, and the value is not in
storing them but in grouping, de-duplicating, mapping violations to causes, and
alerting on the ones that matter. That is a service to build, run, and scale.
CentralCSP is that service. Point the endpoint at it and it collects every report type, groups them, and turns the stream into alerts and exportable evidence, so you skip the collector and start with the useful part.
Confirm it is wired correctly
Use the Reporting API configuration checker to test whether a live site routes its reports correctly, without writing a receiver.
Next steps
- Send your first report in the quickstart.
- Understand batching and delivery in how the Reporting API works.
- For CSP specifically, see where browser CSP reports go and how to receive them.