Sandbox FAQs

📘

BEARER TOKEN LIFESPAN

The lifespan of a Bearer token is one hour (3600 seconds) for both sandbox and production environments.

We recommend automating transactions to use the tokens generated over the token lifespan. Obtaining tokens for each transaction is less efficient and does not improve the security criteria for any transactions.

📘

NOTE

DO NOT perform load testing or production data testing in the sandbox environment. Please use the sandbox ONLY to view sample API responses to HTTP requests using our predefined values and to familiarize yourself with our APIs.

To perform load testing and production data testing, we recommend using our APIs in production environment.

Do you have a sandbox that I can test before signing a contract?

Yes, we do. Please sign up for a sandbox here to test our APIs and familiarize yourself with our APIs without signing a contract without any financial obligations. For more information, see API testing environments. We provide a list of predefined fields and values for sandbox that you can use for testing a variety of responses by using API URLs and endpoints.

How to use test Payers in the sandbox?

See use test payers in sandbox.

The sandbox requires pre-defined groupNumber value but it need not be sent. If you do, it must be one of the accepted pre-defined values, but it is optional. For integration, we need to give QA a way to test and pass one of the pre-defined values. Is it ok to remove it from being sent, what are the pros and cons of doing this in production?

From the TR3 document for the 270/271 transactions, use the Group or Policy Number code only if you cannot determine if the number is a Group Number or a Policy Number. Use codes IG or 6P when they can be determined.
Group numbers are usually tied to a dependent's information on an insurance card. There should not be an issue if you do not have it.

I get an invalid access token error for the API (sandbox). What is wrong?

These are the most common reasons for this issue:

• Access token might not be valid for the selected API or you might have selected one API to test but tried a different API.
  Or
• You might not have followed the Postman instructions correctly.
  Or
• You might have used your own data instead of the our predefined values and fields.
  Or
• You might not have followed the OpenAPI specs (if you are using a different testing environment other than Postman).

To resolve, try requesting for new access token and sending the request again, if the issue persists, perform one of these:

• If you are trying our API in sandbox, contact your sales representative for help or post a question in the developer community.
• If you are a contracted customer, contact support.
• Additionally, if you are either a contracted customer or trying our APIs in sandbox, please plan to attend our office hours, where different Optum departments' representatives would be present, and can answer your queries or help you.

We need to demo for a potential client; which APIs can we integrate with in the sandbox environment to demonstrate the ability to upload claims and, receive and view disputed/rejected claims?

If you do not have a sandbox yet, submit a request through our Developer Portal by clicking Request Sandbox Access. We recommend the Professional Claims v3 API for the demo purpose. This would allow you to submit the required sandbox data while being able to edit key elements in the claim to solicit different edit responses. Real-time demo can be performed by using our Postman collection available here.

I am currently doing FE testing in a staging environment for a client using your APIs to pull up information for users that already have a healthcare plan. I found the sandbox data that can be used, but is there something similar outside of sandbox? I just need to be able to get some sort of data back in order to properly test that the functionality is working, but I would need a user that has a valid member and group ID.

Once you are contracted with Optum, the implementation team can work with you on possible testing scenarios and depending on the internal clearinghouse, your transactions will be assigned.

The sandbox architecture is basically built on STC codes, how do you map CPTs to STC? Also, is there any comprehensive list of CPT codes that you use in order to map CPT To STC?

The current API offering is based of the 270/271 ANSI 5010 transaction. The eligibility request accepts the STC as the standard method of requesting benefits. The specific CPTs associated with those STCs would be specific to the individual responding payer and would need to be confirmed with them directly. A complete list of available STC codes can be found here (please note that only codes dated 2009 are valid).

Can you provide a few sample ICD codes that can generate multiple results in the test environment?

The sandbox returns a canned response based on the received data. There is no validation check or confirmation of specifically required information. These checks only occur in the production environment. The submitted ICD10 codes will receive a successful response as long as they are active and valid codes. If you want to demonstrate the result of submitting an invalid code, you can add a decimal point to the code, which would trigger the error.

When the policy features per-service deductibles, there are deductibles and remaining deductibles associated with specific services (STCs) in the benefits. What happens when the policy lacks per-service deductibles, that is if the policy has only an annual deductible that is the same for all covered services. How would it appear in the sandbox response?

The information will appear the same as the other responses you have received. If only a singular STC is provided, the payer will also return a description field that can be used to apply the information more specifically. They use the description filed as the data could not otherwise be codified.