How and why to move to batch eligibility checks

When providers run thousands of checks at once, such as during a monthly or annual eligibility refresh, payer systems often struggle to keep up. The extra load can cause a payer outage. During an outage, the best thing you can do is retry the failed checks.

If you’re using real-time eligibility checks for bulk checks that aren’t time sensitive, you often end up writing your own logic for queuing, retries, and exponential backoff.

Stedi’s batch eligibility checks handle that work for you.

Batch checks are asynchronous: you submit the checks and collect the results later. You can submit up to 10,000 checks in one request through our API or a CSV upload in the Stedi portal. Stedi queues and retries batch checks automatically. Batch checks also run in a separate pipeline, away from your real-time traffic.

This guide answers questions we commonly hear from teams that move bulk checks from real-time to batch.

When should I use batch checks instead of real-time checks?

Use real-time checks for workflows that need results in seconds. Those can include:

• Checking in a patient at the front desk
• Verifying coverage on the day of the visit
• Testing a new Stedi integration

Use batch checks for bulk workflows that aren’t time sensitive. Those can include:

• Monthly or weekly coverage refreshes
• Upcoming appointments
• Sets of thousands or millions of checks that can run in the background
• Any workflow where a timeline of minutes to hours works

Why do payers struggle with real-time eligibility checks in bulk?

Many payer systems have limited capacity for real-time transactions, such as eligibility checks. Thousands of real-time checks at once can exceed that capacity. This can cause intermittent payer outages.

These outages often occur at the start of each month and each year. That’s when providers and their vendors run bulk eligibility refreshes for all or most of their patients at the same time.

What happens during a payer outage?

During an outage, payers typically return AAA error 42 (Unable to Respond at Current Time). For example, the following response from our Real-Time Eligibility Check JSON endpoint contains AAA error 42:

{
  "errors": [
    {
      "code": "42",
      "description": "Unable to Respond at Current Time",
      "followupAction": "Resubmission Allowed",
      "location": "PAYER"
    }
  ],
  "id": "ec_01a06d4a-a0fa-77d2-8b49-ca9a74c9888c",
  "payerId": "61101"
}

If you get a AAA 42 error, the best practice in most cases is to retry the check.

If you don’t need results in seconds, batch checks give you the best chance of a successful response. Stedi automatically retries checks in a batch that fail due to payer connectivity issues, such as AAA error 42.

By default, Stedi retries these checks for 8 hours. You can extend the retry window to up to 24 hours.

Stedi doesn’t charge for checks that return AAA error 42. That means retrying costs nothing. See Billing for eligibility checks.

I already retry real-time eligibility checks and handle failures. Should I still use batch checks?

Yes, if you don’t need results in seconds. Batch checks often get more successful responses because of their longer retry windows.

For example, during the January 2026 annual refresh period, batch checks saw roughly half the failure rate of real-time checks. Automatic retries with longer windows meant most AAA 42 errors were resolved on their own.

Do batch checks require the same information as real-time checks?

Yes. Batch checks require the same input information as real-time checks, including:

• The payer ID
• The provider’s National Provider Identifier (NPI) or another identifier, like a tax ID
• The patient’s information, like their member ID, date of birth, and name
• The date of service, if it isn’t today
• A Service Type Code (STC) or procedure code, if you need specific benefits

For the required and optional fields, see Request data in our batch eligibility docs.

If you submit checks through the Batch Eligibility Check endpoint, each check also needs a submitterTransactionIdentifier. You use the identifier to match each result to a patient.

Do I need to re-enroll providers for batch checks?

No. Batch checks use the same transaction enrollment as real-time checks. If a provider is already enrolled for real-time checks through Stedi, they don’t need to enroll again.

How is a batch check workflow different from a real-time workflow?

The biggest difference is that batch checks are asynchronous. A real-time check is synchronous: you send the check and get the payer’s response in a single step. The API doesn’t return batch results in the response to your request. Instead, running a batch takes three steps:

1. Submit the batch. Send up to 10,000 checks in one request to the Batch Eligibility Check endpoint. Give each check a submitterTransactionIdentifier, such as your patient ID. Use maxRetryHours to set the retry window. Save the batchId from the response.

   For example, the following request submits two checks with a 24-hour retry window:

   {
     "items": [
       {
         "encounter": {
           "serviceTypeCodes": [
             "30"
           ]
         },
         "provider": {
           "npi": "1234567891"
         },
         "submitterTransactionIdentifier": "ABC123456789",
         "subscriber": {
           "dateOfBirth": "19750101",
           "firstName": "Jane",
           "lastName": "Doe",
           "memberId": "1234567890"
         },
         "tradingPartnerServiceId": "AHS"
       },
       {
         "encounter": {
           "serviceTypeCodes": [
             "30"
           ]
         },
         "provider": {
           "npi": "1234567891"
         },
         "submitterTransactionIdentifier": "DEF123456799",
         "subscriber": {
           "dateOfBirth": "19750101",
           "firstName": "John",
           "lastName": "Doe",
           "memberId": "1234567892"
         },
         "tradingPartnerServiceId": "AHS"
       }
     ],
     "maxRetryHours": 24
   }

   The response includes the batchId:

   {
     "batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
     "submittedAt": "2026-01-02T14:00:00Z"
   }

2. Check the batch status. Call the Retrieve Batch Status endpoint on a schedule. A batch is done when its status is COMPLETED or COMPLETED_WITH_ERRORS.

   For example, the following response shows a completed batch:

   {
     "batchType": "ELIGIBILITY",
     "createdAt": "2026-01-02T14:00:00.000Z",
     "errorCount": 0,
     "id": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
     "inProgressCount": 0,
     "maxRetryHours": 24,
     "name": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
     "source": "API",
     "status": "COMPLETED",
     "successCount": 2,
     "totalCount": 2,
     "updatedAt": "2026-01-02T14:21:37.000Z"
   }

3. Get the results. Page through the Poll Batch Eligibility Checks endpoint, up to 200 results per page. Match each result to a patient with its submitterTransactionIdentifier.

   The following example shows one result:

   {
     "items": [
       {
         "batchId": "01932c61-2d4f-7d22-85fa-c7db2e13e771",
         "benefitsInformation": [
           {
             "code": "1",
             "name": "Active Coverage",
             "planCoverage": "Open Access Plus",
             "serviceTypeCodes": [
               "30"
             ],
             "serviceTypes": [
               "Health Benefit Plan Coverage"
             ]
           }
         ],
         "planStatus": [
           {
             "planDetails": "Open Access Plus",
             "serviceTypeCodes": [
               "30"
             ],
             "status": "Active Coverage",
             "statusCode": "1"
           }
         ],
         "submitterTransactionIdentifier": "DEF123456799",
         "subscriber": {
           "dateOfBirth": "19750101",
           "firstName": "JOHN",
           "lastName": "DOE",
           "memberId": "1234567892"
         },
         "tradingPartnerServiceId": "AHS"
       }
     ],
     "nextPageToken": "945ff6de213d3ef481d028065d4c12fb996a166a3a90ef98564318decfae50ce4b36d74b7e9d9bafa6e1d169"
   }

Each check in a batch request uses the same fields as a Legacy Real-Time Eligibility Check JSON request. Each result uses the same fields as a legacy response. If you use the Real-Time Eligibility Check JSON endpoint, you’ll need to map your checks and results to the legacy format. For the differences, see Response shapes.

The following pseudo-code shows how you could move a scheduled refresh workflow from real-time to batch eligibility checks.

Before: Real-time eligibility checks

for each patient:
  send a real-time eligibility check
  if the response is a AAA 42 error:
    wait, then retry, up to 5 times
  save the response for the patient
  wait before the next check to the same payer

After: Batch eligibility checks

// Submit step
for each group of up to 10,000 patients:
  build one check for each patient
  set submitterTransactionIdentifier to the patient's ID
  send the checks to the Batch Eligibility Check endpoint, with maxRetryHours set to 24
  save the batchId

...

// Collect step
for each saved batchId that isn't done:
  get the batch status
  if the status is COMPLETED or COMPLETED_WITH_ERRORS:
    for each page of results from the Poll Batch Eligibility Checks endpoint:
      save each result for the patient in submitterTransactionIdentifier
    mark the batchId as done

// No retry, backoff, or queuing code.

How can I move to batch checks with limited engineering time?

In most cases, teams only need to add code to submit batches and collect results.

Teams can often remove code, too. Batch checks don’t need logic for retries, backoff, or queuing. That logic is built into the batch checks themselves.

A coding agent, like Claude Code or Codex, can help. Give your agent the following prompt:

Help me migrate any time-insensitive workflows from Stedi's real-time eligibility API endpoint to their batch eligibility API endpoints. Don't change any workflows that run while a person waits for a response in real time.

Read https://www.stedi.com/docs/llms-full.txt, especially these endpoints:
- Batch Eligibility Check: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-batch-eligibility.mdx
- Retrieve Batch Status: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-batch-eligibility-status.mdx
- Poll Batch Eligibility Checks: https://www.stedi.com/docs/healthcare/api-reference/get-healthcare-polling-eligibility.mdx
- Real-Time Eligibility Check JSON: https://www.stedi.com/docs/healthcare/api-reference/post-eligibility-check.mdx
- Legacy Real-Time Eligibility Check JSON: https://www.stedi.com/docs/healthcare/api-reference/post-healthcare-eligibility-legacy.mdx

Find any code that uses a real-time eligibility endpoint for checks that don't need results in seconds, such as scheduled or bulk checks. Replace that code with code that uses the batch eligibility check API endpoints.
Remove code used to retry, back off, and queue eligibility checks in the replaced workflows. Batch eligibility checks handle this for us.

Can I run batch checks without writing code?

Yes. You can use the Stedi portal to run batch checks via CSV upload. We recommend it for one-off batches.

Our CSV upload workflow supports up to 10,000 checks per file – the same limit as our API. For steps, see Upload a CSV file.

How long do batch checks take to run?

Most batches complete in 15-30 minutes. Checks that fail due to payer connectivity issues can take up to the full retry window to return results.

Do batch checks cost more than real-time checks?

No. A batch check costs the same as a real-time check. A batch of 500 checks costs the same as 500 real-time checks.

Get started with Stedi

To get started with Stedi, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.

Batch eligibility checks are available on all paid Stedi plans.