Introduction

The Enhanced Eligibility API extends Optum’s 270/271 JSON-based eligibility workflow with response normalization and optional asynchronous Coverage Discovery. The platform is designed to improve eligibility response consistency, reduce manual follow-up, and simplify payer connectivity.

Real-Time Eligibility is synchronous, while Coverage Discovery is asynchronous. Coverage Discovery paths and add-ons are enabled per customer and are not included automatically. Customers with strict turnaround sensitivity should evaluate Coverage Insight enrollment carefully.

Customers integrate once to Enhanced Eligibility. IMN onboarding is currently required, and Optum may also enable additional managed connectivity paths in some scenarios to expand payer coverage.

This page is the high-level product summary. Use it to understand what the product does, how the major workflows fit together, and which guide to read next.

This page does not contain detailed onboarding checklists, configuration ownership, callback implementation steps, or troubleshooting procedures.

Download The OpenAPI Spec First

The portal UI is useful for browsing endpoints, but it does not expose the full value of the API contract as clearly as the downloaded OpenAPI document. If you only skim the rendered portal pages, you will miss important request and response structure details that matter during implementation.

Download the OpenAPI spec before you build against this API. Use the downloaded file as the source of truth for:

• complete request and response schemas
• example payloads for real-time eligibility and Coverage Discovery workflows
• field names, required properties, enums, and nested object structure
• client generation in your preferred language
• data model generation for request and response validation

To get the most out of this API, the recommended workflow is:

1. Download the OpenAPI spec from the button at the top of this page.
2. Open it in an OpenAPI-capable tool such as Swagger Editor, Postman, Insomnia, or another spec viewer your team already uses.
3. Study the request and response examples for the operations you will implement first, especially the real-time eligibility endpoints and the Coverage Discovery task resources.
4. Generate typed API wrappers and data models in your language using OpenAPI Generator or your team's equivalent tooling.
5. Keep the generated models nearby while building so your request serialization, response parsing, and validation stay aligned with the contract.

If your team generates code from OpenAPI, use this spec to create:

• API clients or service wrappers for the eligibility and Coverage Discovery endpoints
• request and response data models
• validation and serialization code
• mock servers or test fixtures for integration work

Developers who do this up front usually move faster because they can work from concrete examples and strongly typed models instead of reverse-engineering payload shape from the portal UI.

In practical terms, the product supports two primary use cases:

1. Real-time eligibility: Submit a normalized JSON request or raw X12 270 payload and receive a normalized JSON eligibility response.
2. Coverage Discovery: When additional coverage needs to be researched, most customers use the asynchronous Coverage Discovery workflow through the related task links returned from the real-time eligibility response. Coverage Discovery paths and add-ons are enabled per customer and are not included automatically. Direct Coverage Discovery submission is also supported for advanced use cases.

When a customer is enrolled in Coverage Discovery and a real-time eligibility request triggers that workflow automatically, the response link header contains one or more related Coverage Discovery task resources. Those task resources can then be polled or received later through a callback delivery model, depending on your enrollment and integration design.

Most customers should think of Coverage Discovery as an extension of the real-time eligibility workflow rather than as a separate starting point.

In the integrated model, Coverage Discovery reuses information from the original real-time eligibility exchange, and completed results are retrieved later by callback or polling.

Direct Coverage Discovery endpoints are exposed, but they are intended for more advanced implementations that already possess a processed eligibility request and, when needed, a processed eligibility response:

• Direct JSON discovery uses canonical eligibility models
• Direct X12 discovery requires the processed x12-270 and x12-271

In practice, direct X12 discovery is often easier than direct canonical JSON discovery because it avoids mapping into two canonical models.

What The Product Covers

At a high level, Enhanced Eligibility supports four major areas:

1. Real-time eligibility for normalized JSON or X12-driven workflows
2. Stored transaction retrieval for audit, support, and downstream lookup
3. Optional Coverage Discovery for asynchronous follow-up when additional coverage needs to be researched, usually after real-time eligibility
4. Optional value-added behavior such as deduplication, payer aliasing, NPI management, and response normalization

How the Product Fits Together

• Eligibility Requests are the synchronous entry point for real-time benefit checks.
• Transactions allow you to retrieve previously submitted eligibility activity.
• Coverage Discovery is the asynchronous workflow used to search for additional coverage when configured conditions are met.
• Callbacks are the recommended delivery model for completed Coverage Discovery results, especially for high-volume integrations.

Which Guide To Read Next

Use the guide that matches the question you are trying to answer:

Recommended Reading Order

1. Onboarding for Providers & Channel Partners for product and support alignment
2. Developer Onboarding for technical prerequisites and implementation planning
3. Getting Started for the first request, key headers, and implementation patterns
4. Value-Added Features for optional feature purpose, enrollment context, and operational considerations
5. Customer Callback Example API if you will receive Coverage Discovery asynchronously
6. Troubleshooting and Support for the operational runbook

---

📘

For next steps, start with Onboarding for Providers & Channel Partners, then continue to Developer Onboarding.

If onboarding and configuration are already complete, jump directly to Getting Started._