## API Coverage Coverage analysis provides: - **Transparency**: Full visibility of scan execution, with logging of each request - **Actionability**: Step-by-step recommendations for optimal scan configuration > [!TIP] > > **Looking at API Coverage for a WebApp (Frontend) Scan?** > > The coverage view for WebApp scans lists every API request the browser captured while crawling the application. Review capture status to confirm which endpoints the browser reached, and security-check activity to confirm which requests were actively tested. Authentication requests, duplicate exchanges, and endpoints outside the API testing scope can appear as successful (`200`) captures with no active tests. See [WebApp Testing: API Coverage]() and [WebApp Testing: Test Selection]() for selection rules and a diagnostic checklist. ### Automation Via the Public API For CI/CD or other automation, you can retrieve the same aggregate and per-endpoint coverage data over the REST Public API (scan `coverage`, and `GET /v3/scans/{scanId}/targets` for endpoint-level fields). See [Public API: Retrieving API coverage in CI/CD](). ### Reading the Coverage Status Endpoint and GraphQL operation coverage uses the following statuses. `BLOCKLISTED` and `SKIPPED` indicate that no request was sent to the target: - `UNAUTHORIZED`: All requests sent to the endpoint came back with an authentication or authorization error message. - `RATE_LIMIT` (Rate Limit): All requests sent to the endpoint came back with a rate limit error message. - `SERVER_ERROR` (Server Error): All requests sent to the endpoint came back with a server error message. - `REDIRECTION` (Redirection): All requests sent to the endpoint came back with a redirection error message. - `NOT_FOUND` (Not Found): All requests sent to the endpoint came back with a "not found" error message, although it's defined in the schema provided for the scan. A common cause on REST scans is a duplicated base path: the asset URL already ends with `/api` or `/v1` while every OpenAPI path starts with the same prefix, so the scanner calls `/api/api/...`. Look for **Possible duplicated API base path** or **Possible API base path mismatch** in validation events, then point the asset URL at the origin (without the overlapping suffix) or remove that prefix from the spec. - `OK`: At least one request sent to the endpoint doesn't fall into one of the error categories. - `TIMEOUT` (Timeout): A request timed out. - `VALIDATION_ERROR` (Validation Error): A request failed validation. - `REPEATER_ERROR` (Repeater Error): A proxy or Location error prevented the request. - `BROKEN_PIPE` (Broken Pipe): The connection broke while sending a request. - `UNKNOWN` (Unknown): The response classification is unknown. - `BLOCKLISTED`: The endpoint has been blocklisted in the configuration. No request has been sent to it. - `SKIPPED`: The endpoint isn't blocklisted, but still no request has been sent to the endpoint. > [!TIP] > > **Error Message Classification** > > Error classification goes beyond HTTP Status Codes. For example, GraphQL applications often return `200` even for errors. Escape AI intelligently classifies responses based on their content and context. > [!NOTE] > > **Why Are Some of My Endpoints `SKIPPED`** > > The two most common reasons are: > > 1. Server stopped responding (scan stopped early) - check scan results for issues > 2. Speed-focused scan mode selected - consider changing mode for more thorough results > [!NOTE] > > **About the `BLOCKLISTED` Operations** > > Read-only scans exclude operations that the scanner classifies as data-mutating. For GraphQL, this excludes mutations. Review [API Scope]() for additional exclusions. ### How Is Coverage Computed? The endpoints-covered dashboard counts targets with `OK` or `UNKNOWN` coverage as covered. For WebApp scans, capture coverage shows which endpoints the browser reached; security-check activity shows which requests were actively tested. See [WebApp API Coverage](). ### How to Improve Your Coverage? After your first scan, check the `Coverage` panel to analyze your application coverage. Here are key ways to improve coverage: #### Review Read-Only Mode Read-only mode focuses API checks on operations classified as reads. Use read-write mode when your environment permits testing data-mutating operations. See [Production-Safe Scanning]() for browser behavior and safety settings. #### Provide Sufficient Authorization - Configure authentication for endpoints showing `UNAUTHORIZED` errors - Verify token validity by testing with provided `curl` commands - See [Authentication]() for setup details #### Maintain Schema Quality - Provide up-to-date schemas following current standards - Remove deprecated endpoints to improve coverage calculation - Update schema to reflect current endpoint structure - Keep the REST asset URL and spec paths from overlapping. The scanner concatenates them (`asset URL` + spec path). If both include `/api` or `/v1`, coverage fills with `NOT FOUND` on doubled paths. Drop the shared prefix from one side. #### Check Redirections If `/user` redirects to `/user/`, update the schema to match the actual endpoint path. Review redirection responses to check whether authentication or the API URL needs adjustment. #### Ensure Your Server Remains Reachable During the Scan The scan is intense and attempts complex attack scenarios. In some cases, this will make the server unreachable for a few dozen seconds, causing the scan to stop early. By looking at the inferred status code over time or your internal monitoring, you can see if the server has been unreachable during the scan. Making your application more resilient or blocklisting the problematic endpoints can help. #### Make Sure the Scan Is Not Rate Limited Match the scan's request rate to your application or firewall's rate limits using [rate-limiting configuration](). A lower request rate can increase scan duration.