Overview

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

Coverage Discovery paths and add-ons are enabled per customer and are not included automatically.

Coverage Discovery is an async process that initializes discovery paths based on the task(s) enabled for the customer and on the details of the provided canonicalEligibilityRequest and, when available, canonicalEligibilityResponse. canonicalEligibilityRequest is always required. canonicalEligibilityResponse is optional for request-only qualification paths, but should be supplied when path qualification or request-building depends on response-side facts such as response status, payer context, HMO plan information, or Medicare QMB/MBI data. This direct JSON workflow is intended for advanced use cases where the client already has the processed canonical eligibility models available. 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 has more than one enabled task.

Coverage Discovery is asynchronous because some paths involve chained clearinghouse work and additional connected workflow dependencies. 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.

Supported task types are serial and chained. In serial tasks, multiple qualified paths may be initialized under the same task. In chained tasks, later paths may depend on the outcome of earlier paths.

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 enabled for your customer, 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 validates the request against the enrolled discovery paths. The response indicates which paths qualified and which did not.

If successful, the first response is a receipt with either a 200 status for a single task or 207 if the request produced more than one per-task outcome. If no paths qualify, a 422 will be returned for a single task, and a 207 for multi-task responses that include one or more 422 results (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. If this is your first time using callbacks via Swagger, check out the "Callbacks" tab next to "Parameters".

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.