> ## Documentation Index > Fetch the complete documentation index at: https://docs.synthpop.ai/llms.txt > Use this file to discover all available pages before exploring further. # Coverage & authorization > Evaluate eligibility, benefits, and payer rules as part of a validation Task — coverage findings come back in the same result as the clinical verdict. Getting a service approved is rarely a clinical question alone. Even when the documentation is perfect, a request can stall because the patient's plan does not cover it, a prior authorization is missing, or the payer's own rules were not met. Synthpop evaluates **coverage and authorization together with the clinical documentation**, so a single result tells you both whether the request is clinically supported *and* whether it holds up against the patient's payer. **Availability — coverage is evaluated *within* a validation Task.** Coverage and authorization are **not** a separate product or a standalone endpoint. There is no "coverage API" to call. Instead, when you submit a validation Task, Synthpop resolves the patient's payer from the documents you upload and factors payer rules into the outcome. Coverage findings surface in the same [`verdicts`, `issues`, and `verdict_summaries`](/concepts/results) as the clinical result. Some organizations have a coverage-focused `task_type` provisioned; if you need one, ask your Synthpop contact. ## What it does When you create a validation Task, Synthpop reads the payer-relevant material in the packet — insurance cards, demographics, the ordered service, and diagnosis detail — and evaluates the request against the payer's coverage criteria in addition to the clinical criteria. In practice that means: * **Eligibility & benefits.** The patient's carrier is identified from the uploaded documents and used to select the applicable coverage policy. * **Payer rules.** The documentation is checked against what that payer requires to authorize the service — the evidence, orders, and records a reviewer would look for before approving. * **Authorization readiness.** You learn *before you submit to the payer* whether the request is likely to be supported, and exactly what is missing if it is not. Because this runs as part of validation, you don't orchestrate a separate coverage step. You submit the same documents you already have, and the coverage assessment comes back folded into the Task result. ## How coverage findings surface A completed validation Task carries its outcome in three fields of `TaskDetails`. Coverage-related conclusions appear in the same places as clinical ones — there is no separate coverage payload to parse: | Field | What you read | | ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [`verdict_summaries`](/concepts/results) | A plain-English `conclusion` per `code` — the human-readable bottom line, including whether coverage requirements are met. | | [`verdicts`](/concepts/results) | The machine-readable decision per `code`: `approved` true/false, with the `issues` (by index) that affected it. | | [`issues`](/concepts/results) | Every gap Synthpop flagged — including coverage-related ones such as a missing insurance record or an unmet payer requirement — each with a human-readable `message`. | When a request is not supported for a coverage reason, the `verdict` for the affected `code` comes back `approved: false` and references the responsible entry in `issues` by index — the same pattern you already handle for clinical gaps. The example payloads below are **illustrative**. The exact `code` values, issue `key`s, and messages you receive depend on your provisioned `task_type` and the patient's payer. Treat `verdict_summaries` as the human-readable surface and `verdicts` + `issues` as the machine-readable one; don't hard-code specific message strings. A coverage requirement that is satisfied looks no different from any other approval: ```json theme={null} { "status": "completed", "verdict_summaries": [ { "code": "G0399", "conclusion": "Documentation supports the requested service and meets the payer's coverage requirements." } ], "verdicts": [ { "code": "G0399", "approved": true, "issues": [] } ], "issues": [] } ``` When a coverage requirement is *not* met, the gap is described in `issues` and the verdict points at it: ```json theme={null} { "status": "completed", "verdicts": [ { "code": "G0399", "approved": false, "issues": [0] } ], "issues": [ { "key": "task.medical_record.missing", "medical_record_type": "insurance-card", "message": "An insurance card is required to confirm coverage but was not found in the submission." } ] } ``` ## Using it You already know this loop from the [Quickstart](/quickstart) and the [intake walkthrough](/guides/intake/validate-an-order) — coverage adds nothing new to the mechanics. You create a validation Task, poll it to a terminal status, and read the result. Include the insurance card and demographics in the packet alongside the clinical documents. Synthpop uses them to resolve the payer and evaluate coverage. ```bash theme={null} curl -X POST "https://app.synthpop.ai/public/v1/task/create" \ -H "Authorization: Bearer $SYNTHPOP_JWT_TOKEN" \ -F "task_type=task" \ -F "uploads=@referral-packet.pdf;type=application/pdf" \ -F "uploads=@insurance-card.jpg;type=image/jpeg" ``` `task` above is the org-provisioned validation type used throughout these docs; it evaluates clinical *and* coverage requirements together. If your organization has a **coverage-focused `task_type`** provisioned, use that value instead — like every `task_type`, it is assigned during onboarding, not discovered through the API. This value is **illustrative**; your Synthpop contact tells you which types are enabled for you. `GET /task/get` returns the current `TaskDetails`. Poll until the status is `completed`, `failed`, or `invalid`. If the Task stops at `waiting`, it needs more input — often a missing insurance or clinical record — which you supply via `POST /task/{uuid}/upload`. See [Responding to waiting tasks](/guides/responding-to-waiting-tasks). Read `verdict_summaries` for the human-readable conclusion, and `verdicts` + `issues` for the machine-readable decision and the specific coverage gaps. See [Results](/concepts/results) for the full shape. ## Good to know Coverage is evaluated inside a validation Task. You will not find a `/coverage`-style endpoint in the [API reference](/api-reference/introduction), and there is no endpoint that lists coverage capabilities — everything runs through the same `POST /task/create` → `GET /task/get` loop as intake. Synthpop identifies the patient's carrier from the uploaded material (for example, an insurance card). The more complete the payer-relevant documents in the packet, the more precisely coverage can be evaluated — so include the insurance card and demographics when you have them. You don't need a second parser. Coverage conclusions live in the same `verdict_summaries`, `verdicts`, and `issues` your intake integration already reads. A coverage-driven denial is simply a `verdict` with `approved: false` pointing at a coverage-related `issue`. ## Where to go next The concrete end-to-end pattern coverage builds on. The full shape of verdicts, summaries, and issues. The intake capability coverage is evaluated within. Reach patients to close coverage and documentation gaps.