A quick start guide to the Stedi sandbox

Jul 10, 2025

Healthcare

Most developers don’t hate sales. They hate being blocked.

You shouldn’t need to sit through a demo just to run a curl command.

With most dev tools, you can sign up, test things out, and decide for yourself. Stedi is a healthcare clearinghouse, which means we deal with real PHI. That means HIPAA compliance. And that means a BAA before you can send a production request. You can’t just spin up a prod account and start testing.

But we knew devs would want to try things out before committing. That’s why we created sandbox accounts: a free way to test our eligibility API with mock data.

You can sign up for a sandbox and start sending requests in under five minutes. If you’re considering integrating with Stedi, it’s a quick and painless way to try us out.

This guide shows how to set up a sandbox account and send your first mock eligibility check.

What the sandbox supports

The sandbox lets you test real-time 270/271 eligibility checks using mock data.

You can send requests through the JSON API or the Stedi portal. The data is predefined and simulates payers like Aetna, Cigna, UnitedHealthcare, and CMS (Medicare). You can’t use other patient data or select your own payers.

Supported

Not supported

If you need to test these features, contact us to request a free production trial. Most users are up and running in less than a day.

How to get started

Step 1. Create a sandbox account

Go to stedi.com/create-sandbox.

Sign up with your work email. No payment required.

Once in, you’ll land in the Stedi portal.

Step 2. Create a test API key

You’ll need an API key to send mock requests, even in the sandbox.

  • Click your account name in the top right.

  • Select API Keys.

  • Click Generate new API key.

  • Name the key. For example: sandbox-test.

  • Select Test as the mode.

  • Click Generate.

  • Copy and save the key. You won’t be able to see it again.

If you lose the API key, delete it and create a new one.

Step 3. Send a mock eligibility check

You can send mock requests using the Stedi portal or the API. For the API, use the Real-Time Eligibility Check (270/271) JSON endpoint.

Only approved mock requests will work. For a list, see Eligibility mock requests in the Stedi docs. You must use the exact data provided. Don’t change payers, member IDs, birthdates, or names.

An example mock request:

curl --request POST \
  --url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
  --header 'Authorization: Key {test_api_key}' \
  --header 'Content-Type: application/json' \
  --data '{
    "controlNumber":"112233445",
    "tradingPartnerServiceId": "60054",
    "provider": {
        "organizationName": "Provider Name",
        "npi": "1999999984"
    },
    "subscriber": {
        "firstName": "John",
        "lastName": "Doe",
        "memberId": "AETNA9wcSu"
    },
    "dependents": [
        {
            "firstName": "Jordan",
            "lastName": "Doe",
            "dateOfBirth": "20010714"
        }
    ],
    "encounter": {
        "serviceTypeCodes": ["30"]
    }
}'

If you're trying to make sense of the 271 response, check out How to read a 271 eligibility response in plain English. It explains the key fields, common pitfalls, and how to tell what a patient owes.

Step 4. Explore the results in Eligibility Manager

Every check you run is stored in the Stedi portal’s Eligibility Manager.

In Eligibility Manager, you’ll see:

  • A list of submitted mock checks

  • Full request and response payloads

  • A human-readable benefits view

  • Debugging tools to inspect coverage, errors, and payer behavior

Each check is grouped under a unique Eligibility Search ID, so you can track related requests and retries.

Eligibility Manager

Eligibility Manager is especially useful for debugging failed checks. To test failure scenarios, try the predefined mock error cases, like an invalid member ID or provider NPI.

What’s next

The sandbox is the fastest way to test Stedi’s eligibility API. But it’s only mock data and doesn’t support most features.

If you want to test real patient data or try things like insurance discovery, contact us to request a free production trial. We can get most users up and running in minutes.

Most developers don’t hate sales. They hate being blocked.

You shouldn’t need to sit through a demo just to run a curl command.

With most dev tools, you can sign up, test things out, and decide for yourself. Stedi is a healthcare clearinghouse, which means we deal with real PHI. That means HIPAA compliance. And that means a BAA before you can send a production request. You can’t just spin up a prod account and start testing.

But we knew devs would want to try things out before committing. That’s why we created sandbox accounts: a free way to test our eligibility API with mock data.

You can sign up for a sandbox and start sending requests in under five minutes. If you’re considering integrating with Stedi, it’s a quick and painless way to try us out.

This guide shows how to set up a sandbox account and send your first mock eligibility check.

What the sandbox supports

The sandbox lets you test real-time 270/271 eligibility checks using mock data.

You can send requests through the JSON API or the Stedi portal. The data is predefined and simulates payers like Aetna, Cigna, UnitedHealthcare, and CMS (Medicare). You can’t use other patient data or select your own payers.

Supported

Not supported

If you need to test these features, contact us to request a free production trial. Most users are up and running in less than a day.

How to get started

Step 1. Create a sandbox account

Go to stedi.com/create-sandbox.

Sign up with your work email. No payment required.

Once in, you’ll land in the Stedi portal.

Step 2. Create a test API key

You’ll need an API key to send mock requests, even in the sandbox.

  • Click your account name in the top right.

  • Select API Keys.

  • Click Generate new API key.

  • Name the key. For example: sandbox-test.

  • Select Test as the mode.

  • Click Generate.

  • Copy and save the key. You won’t be able to see it again.

If you lose the API key, delete it and create a new one.

Step 3. Send a mock eligibility check

You can send mock requests using the Stedi portal or the API. For the API, use the Real-Time Eligibility Check (270/271) JSON endpoint.

Only approved mock requests will work. For a list, see Eligibility mock requests in the Stedi docs. You must use the exact data provided. Don’t change payers, member IDs, birthdates, or names.

An example mock request:

curl --request POST \
  --url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
  --header 'Authorization: Key {test_api_key}' \
  --header 'Content-Type: application/json' \
  --data '{
    "controlNumber":"112233445",
    "tradingPartnerServiceId": "60054",
    "provider": {
        "organizationName": "Provider Name",
        "npi": "1999999984"
    },
    "subscriber": {
        "firstName": "John",
        "lastName": "Doe",
        "memberId": "AETNA9wcSu"
    },
    "dependents": [
        {
            "firstName": "Jordan",
            "lastName": "Doe",
            "dateOfBirth": "20010714"
        }
    ],
    "encounter": {
        "serviceTypeCodes": ["30"]
    }
}'

If you're trying to make sense of the 271 response, check out How to read a 271 eligibility response in plain English. It explains the key fields, common pitfalls, and how to tell what a patient owes.

Step 4. Explore the results in Eligibility Manager

Every check you run is stored in the Stedi portal’s Eligibility Manager.

In Eligibility Manager, you’ll see:

  • A list of submitted mock checks

  • Full request and response payloads

  • A human-readable benefits view

  • Debugging tools to inspect coverage, errors, and payer behavior

Each check is grouped under a unique Eligibility Search ID, so you can track related requests and retries.

Eligibility Manager

Eligibility Manager is especially useful for debugging failed checks. To test failure scenarios, try the predefined mock error cases, like an invalid member ID or provider NPI.

What’s next

The sandbox is the fastest way to test Stedi’s eligibility API. But it’s only mock data and doesn’t support most features.

If you want to test real patient data or try things like insurance discovery, contact us to request a free production trial. We can get most users up and running in minutes.

Most developers don’t hate sales. They hate being blocked.

You shouldn’t need to sit through a demo just to run a curl command.

With most dev tools, you can sign up, test things out, and decide for yourself. Stedi is a healthcare clearinghouse, which means we deal with real PHI. That means HIPAA compliance. And that means a BAA before you can send a production request. You can’t just spin up a prod account and start testing.

But we knew devs would want to try things out before committing. That’s why we created sandbox accounts: a free way to test our eligibility API with mock data.

You can sign up for a sandbox and start sending requests in under five minutes. If you’re considering integrating with Stedi, it’s a quick and painless way to try us out.

This guide shows how to set up a sandbox account and send your first mock eligibility check.

What the sandbox supports

The sandbox lets you test real-time 270/271 eligibility checks using mock data.

You can send requests through the JSON API or the Stedi portal. The data is predefined and simulates payers like Aetna, Cigna, UnitedHealthcare, and CMS (Medicare). You can’t use other patient data or select your own payers.

Supported

Not supported

If you need to test these features, contact us to request a free production trial. Most users are up and running in less than a day.

How to get started

Step 1. Create a sandbox account

Go to stedi.com/create-sandbox.

Sign up with your work email. No payment required.

Once in, you’ll land in the Stedi portal.

Step 2. Create a test API key

You’ll need an API key to send mock requests, even in the sandbox.

  • Click your account name in the top right.

  • Select API Keys.

  • Click Generate new API key.

  • Name the key. For example: sandbox-test.

  • Select Test as the mode.

  • Click Generate.

  • Copy and save the key. You won’t be able to see it again.

If you lose the API key, delete it and create a new one.

Step 3. Send a mock eligibility check

You can send mock requests using the Stedi portal or the API. For the API, use the Real-Time Eligibility Check (270/271) JSON endpoint.

Only approved mock requests will work. For a list, see Eligibility mock requests in the Stedi docs. You must use the exact data provided. Don’t change payers, member IDs, birthdates, or names.

An example mock request:

curl --request POST \
  --url 'https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3' \
  --header 'Authorization: Key {test_api_key}' \
  --header 'Content-Type: application/json' \
  --data '{
    "controlNumber":"112233445",
    "tradingPartnerServiceId": "60054",
    "provider": {
        "organizationName": "Provider Name",
        "npi": "1999999984"
    },
    "subscriber": {
        "firstName": "John",
        "lastName": "Doe",
        "memberId": "AETNA9wcSu"
    },
    "dependents": [
        {
            "firstName": "Jordan",
            "lastName": "Doe",
            "dateOfBirth": "20010714"
        }
    ],
    "encounter": {
        "serviceTypeCodes": ["30"]
    }
}'

If you're trying to make sense of the 271 response, check out How to read a 271 eligibility response in plain English. It explains the key fields, common pitfalls, and how to tell what a patient owes.

Step 4. Explore the results in Eligibility Manager

Every check you run is stored in the Stedi portal’s Eligibility Manager.

In Eligibility Manager, you’ll see:

  • A list of submitted mock checks

  • Full request and response payloads

  • A human-readable benefits view

  • Debugging tools to inspect coverage, errors, and payer behavior

Each check is grouped under a unique Eligibility Search ID, so you can track related requests and retries.

Eligibility Manager

Eligibility Manager is especially useful for debugging failed checks. To test failure scenarios, try the predefined mock error cases, like an invalid member ID or provider NPI.

What’s next

The sandbox is the fastest way to test Stedi’s eligibility API. But it’s only mock data and doesn’t support most features.

If you want to test real patient data or try things like insurance discovery, contact us to request a free production trial. We can get most users up and running in minutes.

Share

Twitter
LinkedIn

Get started with Stedi

Get started with Stedi

Automate healthcare transactions with developer-friendly APIs that support thousands of payers. Contact us to learn more and speak to the team.

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Get updates on what’s new at Stedi

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.