# Overview (/en/docs/web-security/reporting-api)



The Reporting API is the browser mechanism for collecting events that happen on a
page, policy violations, network errors, deprecations, interventions, and crashes,
and delivering them to an endpoint you control. You declare an endpoint with one
HTTP header, point a policy at it, and the browser sends structured JSON reports
out of band. This documentation is a plain-language standards reference for the
whole surface: what the API is, how to set up every reporting header, and what
each policy and report type means.

CentralCSP is built on this API. It collects and aggregates every report type at a
single endpoint, then turns the stream into [client-side security monitoring](/en/docs/platform/monitoring)
and PCI DSS v4 evidence, with [Content Security Policy (CSP)](/en/docs/web-security/policies/content-security-policy) as the deepest use case.

## What the Reporting API is [#what-the-reporting-api-is]

It helps to separate two roles. A **policy** or platform feature is the producer of
a report: Content Security Policy, Cross-Origin-Opener-Policy, Network Error
Logging, a deprecation warning, a crash. The Reporting API is the shared transport
underneath them: a queue in the browser that collects those reports and delivers
them. The producer decides what is worth reporting; the API decides how it travels.

Three terms run through this reference. A **report** is a single JSON object
describing one event (one CSP violation, one network failure). An **endpoint** is a
URL you control that receives reports, named in a header. A **policy** is a set of
rules the browser enforces, configured by a response header, that can name an
endpoint to report to. The API itself defines no policy behavior; it only structures,
queues, and delivers what the policies produce.

One expectation to set early: delivery is best-effort, not a guaranteed channel. The
specification says so explicitly. Reports can be batched, delayed, deduplicated, or
dropped, so treat the stream as a high-value signal, not a complete audit log.

## How it works [#how-it-works]

A policy flags an event. The browser does not send it immediately; it collects the
report, batches it with others, and POSTs the batch to the named endpoint as
`application/reports+json`, on its own schedule. Delivery runs independently of the
page, which is why a report can still arrive after the page has navigated away or
even crashed.

```mermaid
flowchart LR
  A["Page + policy<br/>(CSP, COOP, NEL)"] -->|flags an event| B["Browser<br/>report queue"]
  B -->|batches, out of band| C["POST<br/>application/reports+json"]
  C --> D["Your reporting<br/>endpoint"]
```

```http
Reporting-Endpoints: csp-endpoint="https://<Endpoint-ID>.report.centralcsp.com"
```

```http
Content-Security-Policy: default-src 'self'; report-to csp-endpoint
```

## What you can do with it [#what-you-can-do-with-it]

* **Catch CSP violations** before users report a broken or attacked page, with the [`csp-violation` report](/en/docs/web-security/reporting-api/reports/csp-violation).
* **Inventory the scripts** running in the browser via CSP hash reporting, the [`csp-hash` report](/en/docs/web-security/reporting-api/reports/csp-hash), the basis of a [script inventory and SBOM](/en/docs/platform/features/script-inventory).
* **Monitor network failures** your server never sees (DNS, TLS, connection) with [Network Error Logging](/en/docs/web-security/policies/network-error-logging) and the [`network-error` report](/en/docs/web-security/reporting-api/reports/network-error).
* **See deprecations and interventions** before they break the site, with the [`deprecation`](/en/docs/web-security/reporting-api/reports/deprecation) and [`intervention`](/en/docs/web-security/reporting-api/reports/intervention) reports.
* **Get crash signals** from real users with the [`crash` report](/en/docs/web-security/reporting-api/reports/crash).
* **Roll out cross-origin policies safely** (COOP, COEP, Permissions-Policy) in report-only mode and watch what would break.

CentralCSP collects all of these at [one endpoint](/en/docs/platform/monitoring) and turns them into alerts and evidence.

## In this reference [#in-this-reference]

<Cards>
  <Card title="Concepts" href="/en/docs/web-security/reporting-api/concepts/how-the-reporting-api-works" description="How delivery and batching work, the report format, and Report-To vs Reporting-Endpoints." />

  <Card title="Headers" href="/en/docs/web-security/reporting-api/headers" description="Declare endpoints and route reports with Reporting-Endpoints and Report-To." />

  <Card title="Report types" href="/en/docs/web-security/reporting-api/reports" description="One page per report payload, with its shape and meaning." />

  <Card title="Policies" href="/en/docs/web-security/policies" description="How each configurable policy works and how it reports. CSP is the deepest sub-tree." />
</Cards>

## Get started [#get-started]

The shortest path is to declare one endpoint and confirm a first report arrives.
See [Get started](/en/docs/web-security/reporting-api/get-started). To check whether a live site is wired up
correctly, use the [Reporting API configuration checker](/tools/reporting-api).

## Sources [#sources]

* [W3C, Reporting API](https://www.w3.org/TR/reporting-1/)
* [MDN, Reporting API](https://developer.mozilla.org/en-US/docs/Web/API/Reporting_API)
* [Chrome, the Reporting API](https://developer.chrome.com/docs/capabilities/web-apis/reporting-api)