> ## Documentation Index > Fetch the complete documentation index at: https://stedi.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Eligibility Manager Eligibility Manager provides insight into your eligibility check pipeline and helps you identify, diagnose, and fix failed eligibility checks. For example, you can filter for all of the eligibility checks that failed during a payer outage and retry once the payer is back online. In the app, you can: * Review every eligibility check you submit through the app or Stedi APIs. * Search and filter historical eligibility checks by status, Payer ID, date, and error code. * Edit and retry failed eligibility checks and review the details of each attempt. * Use the Debug view to systematically troubleshoot failed eligibility checks until you receive a successful response from the payer. ## Example troubleshooting workflow The following example shows how Eligibility Manager can help you track and resolve eligibility check failures: You submit an eligibility check through Stedi's [Eligibility Check API](/api-reference/healthcare/post-healthcare-eligibility) for Nick Smith. Stedi sends it to the payer and creates a new eligibility search record in the app containing the request details. The payer returns an [AAA error](/healthcare/eligibility-troubleshooting#payer-aaa-errors) code `75` - Subscriber/Insured Not Found. Eligibility Manager shows that the status for the new eligibility search is `Failed`. You open the eligibility search, diagnose the error, correct the subscriber's first name to "Nicholas", and submit the updated eligibility check. Stedi stores the updated request as another entry in the existing eligibility search. The payer returns a successful response showing active insurance coverage for Nicholas Smith. The status of the Eligibility Search changes to `Active`, and you can view the request and response details for both iterations of the eligibility check - the original failure and the successful retry - within the same eligibility search record. ## Eligibility search Eligibility Manager stores eligibility check requests in groups called eligibility searches. When you submit an eligibility check through the app or API, Stedi creates a new eligibility search record. Every time you retry that eligibility check, Stedi stores the retry details within the existing eligibility search. This creates a clear timeline of troubleshooting efforts for failed requests. ### Create You can create a new eligibility search through the app or Stedi APIs. * **App:** Click **New search** and enter the eligibility check details into the interactive form. * **API:** Use the [Eligibility Check API](/api-reference/healthcare/post-healthcare-eligibility) to submit an eligibility check programmatically. Once you submit the eligibility check, Stedi creates a new eligibility search in the app. #### External Patient ID You can optionally add a **External Patient ID** to the request. This should be a unique identifier for the patient in your system. Adding this identifier helps you identify eligibility checks for the same patient over time. ### Filter You can filter eligibility searches by the following criteria: * **Error code:** By the [AAA code](/healthcare/eligibility-troubleshooting#payer-aaa-errors) returned by the payer. For example, `42` errors indicate a connectivity issue. * **Payer:** By the Payer ID (62308) or business name (such as Cigna) * **Status:** By Queued, Started, Failed, Inactive, and Active * **Date:** A date range for when the initial eligibility check within an eligibility search was submitted. For example, a filter beginning on October 1st would only include eligibility searches with an initial submission on or after October 1st. It would *not* include an eligibility search with an initial submission on September 30th and a retry on October 1st. * **Available actions:** Immediately find all eligibility searches that are eligible to edit and retry (errors in the request data) or retry without edits (error codes `42` and `80`, which indicate payer connectivity issues). Results are sorted by the date of the original eligibility check within the eligibility search, with the most recent listed first. ### Statuses The status of an eligibility search is determined by the most recent eligibility check in the record. For example, if the most recent iteration of a check failed, the status of the entire eligibility search is `Failed`, even if a previous version of the request succeeded. An eligibility search can have one of the following statuses: * **Queued:** Stedi placed the eligibility check in its internal queue and will send it to the payer when resources are available. This status is common when you schedule batch eligibility check refreshes through the API or perform large bulk retries that exceed your account's concurrency budget. You can typically expect the status to change to `Started` within a few seconds. * **Started:** Stedi sent your eligibility check to the payer and is waiting for a response. * **Failed:** The payer returned an error code in the response. Review the error code and retry the eligibility check. * **Inactive:** The payer's response doesn't contain an active eligibility and benefit type. * **Active:** The payer's response contains an active eligibility and benefit type (codes 1-5). Visit [Eligibility and benefit type codes](/healthcare/eligibility-active-coverage-benefits#benefit-type-codes) for a complete list. ## Retry failed eligibility checks Eligibility Manager allows you to edit the request details and retry eligibility checks until you get a successful response. You can choose to retry the entire eligibility search (the most recent iteration of the eligibility check) or select a specific iteration to retry. To resubmit an eligibility check, click an eligibility search to review its details and then click **Edit and retry**. Stedi opens a submission form prepopulated with the request details from the iteration you selected. You can update the patient information, service type codes, and other properties as needed, and then click **Submit** to retry the eligibility check. You'll know the retry was successful when the status of the eligibility search is either `Active` or `Inactive`. Once a retry is successful, you can view the raw request data for the successful check and use it to make a call to Stedi's [Eligibility Check API](/api-reference/healthcare/post-healthcare-eligibility). ### Debug view Click **Debug** within an eligibility search to enter a workspace where you can systematically troubleshoot failed eligibility checks until you receive a successful response from the payer. For example, first you might try swapping the patient's nickname (Dave) for their full name (David) to see if that returns benefits information. In the next iteration, you might try submitting the request with a different service type code or dropping the date of birth. Debug view shows all past iterations of the eligibility check and highlights the differences between each new version of the request. You can also draft and submit new requests directly from this page. This format helps you understand what you've already tried and quickly iterate on failed requests. ### Batch retry Error codes `42` and `80` indicate that an eligibility check failed because of a connectivity issue between Stedi and the payer. Common causes include payer outages, payer throttling, and that the transaction timed out. Visit [Eligibility troubleshooting](/healthcare/eligibility-troubleshooting#errors) for complete details. You can filter for all eligibility searches with error codes `42` and `80` by selecting **Available actions: Retry**. Then, you can perform a batch retry for up to 50 failed requests at a time. This action automatically resubmits the most recent eligibility check within each eligibility search. This approach is useful when you need to retry multiple eligibility checks that failed during a payer outage.