Overview

You must be enrolled in the Coverage Discovery feature in order to use this system!

Coverage Discovery is an async process that initializes new coverage discovery paths, based on the task(s) defined on the active customer configuration and on the details of the provided x12-270 and x12-271. Both fields are required. This direct X12 workflow is often simpler than the canonical JSON discovery workflow because it allows clients to submit the processed X12 pair without mapping into two canonical models. If successful, the initial response is either a 202 Accepted receipt for a single record or a 207 Multi-Status response if more than one record was produced from the request and the customer is configured for multiple tasks.

Coverage Discovery is asynchronous because some paths involve chained clearinghouse work and external vendor dependencies such as MBI lookup. Most non-Coverage-Insight paths are near real time relative to traditional discovery workflows, while RTCOB is typically the longest of those near-real-time paths. Customers with strict turnaround sensitivity should evaluate Coverage Insight enrollment carefully.
Coverage Discovery paths may also participate in customer-configured deduplication. This can be enabled per path rather than uniformly across every path. RTCOB and Coverage Insight additionally use a separate non-configurable 72-hour request cache. When that cache is hit, the path is added to discoveryPaths.skipped instead of creating a new downstream submission.
To test if the request meets conditions to generate tasks, see the Dry Run section.

Async Delivery Flow

1. Submit the Coverage Discovery request.
2. If dryRun is false, the API accepts work for asynchronous processing.
3. For single-task execution, a 202 Accepted response includes a location header for the created discovery task resource.
4. For multi-task execution, a 207 Multi-Status response returns per-task results, and accepted items include an href for each created task resource.
5. Your callback endpoint later receives the completed task payload asynchronously at callbackUrl.
6. If needed, you can poll /coverage-discovery/{id} using the task resource returned in location or href.

Dry Run

To validate that your request meets expected conditions for the paths in which your tasks are configured, include dryRun = true in the request body. In dry-run mode, the request does not execute discovery, does not create task records, and does not send a callback. Instead, the endpoint verifies the request against the configured paths in the rules engine. The response indicates which paths met conditions and which paths failed validation.

If successful, the first response is a receipt with either a 200 status for a single task or 207 if more than one task was produced with a status(es) of 200 in the request body. If no paths qualify, a 422 will be returned for a single task, and a 207 for multi-task with status(es) 422 in the request body (see DryRunMultiStatusMixedResponse example).

Callback API

Due to the long-running nature of the discovery process, completed task responses are communicated asynchronously to request.callbackUrl. callbackUrl is required on this request body, including when dryRun is true.

The API specified in the callbackUrl that will receive the asynchronous response once discovery finishes must meet the customer-specific whitelisting requirements defined by your team. Please reach out to support if you need to configure whitelisting. This API must meet the callback structure documented in the "CustomerCallbacks" tab.

Your callback implementation should treat deliveries as asynchronous webhook-style notifications and should be prepared to process the same task idempotently if a delivery is retried. The callback payload uses the same CoverageDiscoveryTask model returned by GET /coverage-discovery/{id}. The most important fields for most clients are the task id, task status, any error or failure details, and the embedded real-time eligibility content when callback consolidation is enabled.

If you are unsure about the details of your request and how they might produce eligible discovery paths, you can use dryRun to test the request without executing any transactions. When dryRun is enabled, the response is synchronous and the callback is not invoked.