Technical Reference Guide

📘

NOTE

Please use the table of contents on the right side of this page to quickly navigate to a desired section.

API Data dictionary

The following data dictionary includes all the essential information you will need to integrate with our Dental Claim Submission API and serves as a ready reference source should you encounter a problem. It is intended to support developers, analysts and stakeholders in understanding the structure, usage, and expected values of the data exchanged through the system.

Use this data dictionary:

  • As a reference when integrating with or troubleshooting the API/data interface.
  • Ensure all required fields are populated when constructing requests.
  • Refer to HTTP status codes section for guidance on resolving issues.

Query examples — See the following example queries or API requests that illustrate the usage and expected formats; useful for developers and testers to understand expected formats and usage patterns.

Request body — Defines the input parameters required for API calls or data queries. Includes field names, data types, required/optional status, and descriptions.

Parameters — Provide required and optional fields for the API calls.

Response body — Lists the fields returned in the response payload. Includes field names, data types, formats, and descriptions.

📘

NOTE

Please note that our APIs are private and secure, and require unique credentials to generate a Bearer token and gain access to. Please (generate a Bearer token based on your API environment) to obtain access to our APIs.

URLs

SandboxProduction
Generate Bearer tokenhttps://sandbox-apigw.optum.com/apip/auth/sntl/v1/token

Health checkhttps://sandbox-apigw.optum.com/py/oihub/claim/dnt/submit/v1/health-check

Dental Claim Submissionhttps://sandbox-apigw.optum.com/py/oihub/claim/dnt/submit/v1/graphql
Generate Bearer tokenhttps://apigw.optum.com/apip/auth/sntl/v1/token

Health checkhttps://apigw.optum.com/py/oihub/claim/dnt/submit/v1/health-check

Dental Claim Submissionhttps://apigw.optum.com/py/oihub/claim/dnt/submit/v1/graphql

Generate a Bearer token

Click Generate Bearer Token for Optum Real Dental APIs, for steps, see Generate a Bearer Token.

Claim Submission OpenAPI Spec

To download, click Claim Submission OpenAPI spec .

Perform API health check

All our API collections include a /healthcheck endpoint to verify that the connection to the API server is established and the API is operational. Our APIs can be accessed securely using Bearer token.

📘

API TESTING/USING

  • In our developer portal TryIt! interface
    • You need to reapply the Bearer token within the Bearer token expiry span by entering it in the CREDENTIALS box to test/use different APIs.
  • In your development platform
    • The generated Bearer token need not be reapplied or re-entered to test/use different APIs; the same Bearer token will be used across all transactions during the full token lifespan, and you can automatically refresh the token just before it expires.

In the developer portal Try It! interface

  1. Paste the Bearer token (generated as mentioned in the preceding section) in the CREDENTIALS >> Bearer box as mentioned in the Generate a Bearer token section above.
  2. Click Try It! under the cURL Request box.

If the request was successful, the response shows such as, {"message": "Service is healthy"} in the RESPONSE box to indicate that the APIs are operational and are accessible. If the request failed, the reason shows in the RESPONSE box as listed in the HTTP Status Codes section at the end of this page or click the link in the TOC on the right.

Note that each API health message depends on the API being tested/used.

Reference: HTTP Status Codes

In your development platform

  1. Download our OpenAPI Spec (for example, to access a product OpenAPI spec you are using/testing, go to the required API Overview section >> click Download OpenAPI Spec.) and import it into the API project in your development platform.
  2. Expand the API collection folder and click the Get Token endpoint to generate a Bearer token.
  3. Click the Body tab and enter your unique secure credentials.
    • grant_type: client_credentials
    • client_id: your client_id
    • client_secret: your client_secret
    1. Send the request to generate a Bearer token.
  4. Now, click the /healthcheck endpoint and send it view if the connection to the API server was established.

Apply the same token across all transactions during the full token lifespan and automatically refresh the token just before it expires.

If the request was successful, the response shows such as, {"message": "Service is healthy"} in the RESPONSE box to indicate that the APIs are operational and are accessible. If the request failed, the reason shows in the RESPONSE box as listed in the HTTP Status Codes section at the end of this page or click the link in the TOC on the right.

Note that each API health message depends on the API being tested/used.

Reference: HTTP Status Codes

Run Dental Claim Actions

submit/v1/graphql (link to Dental Claims API) — Providers and practice management systems can submit the X12 EDI 837D-compliant dental claims to payers through the Clearing House.

👍

TIP

  1. Choose an option to test/use our APIs, that is, in our developer portal TryIt! interface (you need to copy and paste the unexpired Bearer token generated for testing the Healthcheck) and/or in your development platform.
  2. Repeat the steps provided in the Perform API Healthcheck >> In your developer platform or In our developer portal TryIt! interface section.
    You can use the example field values provided in the Parameters table).

Parameters

ParameterIn Developer PortalIn Development PlatformDescription
queryEnter the query field request data (example given below)Click the Body tab to enter (see the following example)GraphQL query for the Dental Claims Actions (pre-populated in Try It! interface) (required)
x12RequestDataExpand (press the + symbol) the variables >> input >> input objects to enter the X12 request data (example given below)Click the Body tab to enter (see the following example)Contains 837X12 request data for Institutional/Professional claims. MUST pass member ID, First Name, Last Name, DOB, and TIN (pre-populated in Try It! interface) (Required)
payerIdExpand (press the + symbol) the variables >> input >> input objects to enter the payer IDClick the Params tab to addYour 5-digit payer ID (pre-populated in Try It! interface) (required), example, 88848
providerTaxIdEnter the provider's tax IDClick the Params tab to addProvider ID (example, 999999)
x-optum-consumer-correlation-idEnter the x-optum-consumer-correlation-id (your gateway identifier)Click the Params tab to addExample: test_dnt-claim-submission-200_success

📘

NOTE

Check the Headers and Body parameters to make sure that the values comply with the parameters provided in the Parameters table.

❗️

IMPORTANT

Please do not submit PHI or PII data on the developer portal's Try It! interface.

mutation claimActions($input: ClaimSubmissionInput!) { claimSubmission(input: $input) { transactionId x12ResponseData responseType x12Response277CA message statusCode } }
  
ISA*00*          *00*          *ZZ*DENTAL123      *ZZ*PAYER456       *260113*1430*^*00501*000000001*0*P*:~GS*HC*DENTAL123*PAYER456*20260113*1430*1*X*005010X224A2~ST*837*0001*005010X224A2~BHT*0019*00*D001*20260113*1430*CH~NM1*41*2*ABC DENTAL*****XX*1234567890~PER*IC*CONTACT*TE*5551234567~NM1*40*2*DELTA DENTAL*****46*98765~HL*1**20*1~PRV*BI*PXC*1223G0001X~NM1*85*2*ABC DENTAL*****XX*1234567890~N3*555 DENTAL DR~N4*CITY*ST*12345~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******CI~NM1*IL*1*SMITH*JANE****MI*ABC123456~N3*456 ELM ST~N4*CITY*ST*12345~DMG*D8*19800101*F~NM1*PR*2*DELTA DENTAL*****PI*98765~CLM*D001*150***11:B:1*Y*A*Y*Y~DTP*431*D8*20260110~REF*D9*REF789~HI*ABK:K0210~LX*1~SV3*AD:D0120*150**1~TOO*JP*4~DTP*472*D8*20260110~SE*23*0001~GE*1*1~IEA*1*000000001~

Enter the information as mentioned in the preceding table and click TryIt! in the developer portal or click Send in your development platform.

❗️

IMPORTANT

Please note that the request requires you to provide all the required field values. Please note that these required values are GREYED out, which are pre-populated example values and can be selected to view the canned response. To view the required fields, expand the + symbol (indicated by the variables field below.

{
"data": {
  "claimSubmission": {
   "transactionId": "5ZHN1777891946530211",
   "x12ResponseData": "ISA*00*          *00*          *ZZ*DENTAL123      *ZZ*PAYER456       *260113*1430*^*00501*000000001*0*P*:~GS*HC*DENTAL123*PAYER456*20260113*1430*1*X*005010X224A2~ST*837*0001*005010X224A2~BHT*0019*00*D001*20260113*1430*CH~NM1*41*2*ABC DENTAL*****XX*1234567890~PER*IC*CONTACT*TE*5551234567~NM1*40*2*DELTA DENTAL*****46*98765~HL*1**20*1~PRV*BI*PXC*1223G0001X~NM1*85*2*ABC DENTAL*****XX*1234567890~N3*555 DENTAL DR~N4*CITY*ST*12345~REF*EI*123456789~HL*2*1*22*0~SBR*P*18*******CI~NM1*IL*1*SMITH*JANE****MI*ABC123456~N3*456 ELM ST~N4*CITY*ST*12345~DMG*D8*19800101*F~NM1*PR*2*DELTA DENTAL*****PI*98765~CLM*D001*150***11:B:1*Y*A*Y*Y~DTP*431*D8*20260110~REF*D9*REF789~HI*ABK:K0210~LX*1~SV3*AD:D0120*150**1~TOO*JP*4~DTP*472*D8*20260110~SE*23*0001~GE*1*1~IEA*1*000000001~",
   "responseType": "277CA",
   "x12Response277CA": "ISA*00*          *00*          *ZZ*PAYER456       *ZZ*DENTAL123      *260504*0552*^*00501*124055228*0*P*:~GS*HN*PAYER456*DENTAL123*20260504*0552*1*X*005010X214~ST*277*000000001*005010X214~BHT*0085*08*62BC0300000000008253*20260504*055228*TH~HL*1**20*1~NM1*AY*2*OPTUM*****FI*841162764~TRN*1*62BC0300000000008253~DTP*050*D8*20260504~DTP*009*D8*20260504~HL*2*1*21*1~NM1*41*2*ABC DENTAL*****46*1234567890~TRN*2*D001~STC*A1:19:AY*20260504*WQ*150~QTY*AA*1~AMT*YY*150~HL*3*2*19*1~NM1*85*2*ABC DENTAL*****XX*1234567890~TRN*1*62BC0300000000008253~STC*A1:19:AY**WQ*150~REF*TJ*123456789~QTY*QC*1~AMT*YY*150~HL*4*3*PT~NM1*QC*1*SMITH*JANE****MI*ABC123456~TRN*2*D001~STC*A3:21:40*20260504*U*150********H H20204 Code Value 'XX' at element 'NM108' in segment 'Submitter Name' is valid in the X12 standard, but not in this HIPAA implementation.~STC*A3:153:40*20260504*U*150********H H24402 The value '1234567890' fails the check digit algorithm for the \"HIPAA National Provider ID (NPI)\".~STC*A3:21:40*20260504*U*150********H H10904 Number of Included Segments '23' as indicated in SE01 does not match actual segment count '27'.~STC*A3:153:40*20260504*U*150********H H24402 The value '1234567890' fails the check digit algorithm for the \"HIPAA National Provider ID (NPI)\".~STC*A3:21:40*20260504*U*150********H H20204 Code Value '431' at element 'DTP01' in segment 'Date - Accident' is valid in the X12 standard, but not in this HIPAA implementation.~STC*A3:26:40*20260504*U*150********H NDN044  Invalid Payer ID Submitted on Claim~REF*D9*REF789~SE*31*000000001~GE*1*1~IEA*1*124055228~",
   "message": "Dental claim submitted successfully. Refer 277CA for validation outcomes.",
   "statusCode": "000"
  }
}
}

👍

TIP

  1. Choose an option to test/use our APIs, that is, in our developer portal TryIt! interface (you need to copy and paste the unexpired Bearer token generated for testing the Healthcheck) and/or in your development platform.
  2. Repeat the steps provided in the Perform API Healthcheck >> In your developer platform or In our developer portal TryIt! interface section.
    You can use the example field values provided in the Parameters table).

If the request failed, the reason shows in the response box. Here are the HTTP Error Codes.

API Setup

For information about, setting your API test environment, please see API Setup.

Subscribe to live and mock data testing in sandbox

Please see Subscribe to live and mock data testing in sandbox.

Integrate our APIs in production environment

Please see Integrate our APIs in production environment.

HTTP Status Codes

The following table provides error codes, including code values and error messages.