POST
/
change
/
medicalnetwork
/
professionalclaims
/
v3
/
raw-x12-submission

This endpoint sends 837P (professional) claims to payers in raw X12 EDI format. This is ideal if you have an existing system that generates X12 EDI files and you want to send them through Stedi’s API.

  • Call this endpoint with a payload in 837 X12 EDI format.
  • Stedi validates the EDI and sends the claim to the payer.
  • The endpoint returns a response from Stedi in JSON format containing information about the claim you submitted and whether the submission was successful.

Send test claims

All claims you submit through this endpoint are sent to the payer as production claims unless you explicitly designate them as test data.

To send test claims, set the usageIndicator field in the test claim to T. This allows you to filter for test claims on the Transactions page in the Stedi app.

Note that you will receive a 277 Claim Acknowledgment in response to test claims, allowing you to test your workflow end to end, but you will not receive a test 835 (ERA) response.

Identify service lines

A claim can contain multiple service lines. Since the payer may accept, reject, or pay a subset of those lines, you can receive an 835 response that references a patientControlNumber, but only pertains to some of the service lines.

However, the claimInformation.serviceLines.providerControlNumber serves as a unique identifier for each service line in your claim submission. This value appears in the 277CA and 835 ERA responses as the lineItemControlNumber, allowing you to correlate these responses to specific service lines from the original claim. If you don’t set the providerControlNumber for a service line, Stedi uses a random UUID.

Stedi returns service line identifiers in the claimReference.serviceLines object of the synchronous API response.

Character restrictions

Only use the following characters as delimiters: ~, *, : and ^. The X12 format doesn’t support using escape sequences, so you can’t include delimiters or special characters as part of the request data. Stedi returns a 400 error if you include restricted characters as anything other than delimiters in the request.

Enhanced validation

You can optionally set the Stedi-Validation header to snip for enhanced validation on your claim submission.

Enhanced validation uses hundreds of additional edits (the industry term for validation rules) to increase claim acceptance rates. These include Strategic National Implementation Process (SNIP) validations. Stedi also automatically fixes common errors and monitors payer rejections to proactively build out new rules.

There is an additional cost per claim submission when you use enhanced validation. Please reach out to support for access and pricing information.

Authorizations

Authorization
string
headerrequired

A Stedi API Key for authentication.

Headers

Stedi-Transaction-Setting-Id
string

The outbound transaction setting ID. This option only needs to be specified if a non-default release of the Professional Claims guide needs to be used.

Stedi-Validation
string

Set to snip for enhanced validation on this claim. Enhanced validation uses hundreds of additional 'edits' (the industry term for validation rules) to increase claims acceptance rates. Stedi also monitors your 277 rejections to proactively build rules based on previous failures. When possible, Stedi automatically fixes common errors (such as invalid date/time formats and character encoding issues) before sending the claim, reducing payer rejections. There is an additional cost per claim submission when you use enhanced validation. Please reach out to support for access and pricing information.

Body

application/json
x12
string
required

Response

200 - application/json
status
string

The status of the claim submission.

controlNumber
string

An identifier for the transaction.

tradingPartnerServiceId
string

An ID for the payer you identified in the original claim. This value may differ from the tradingPartnerServiceId you submitted in the original request because it reflects the payer's internal concept of their ID, not necessarily the ID Stedi uses to route requests to this payer.

claimReference
object

Information about the claim.

errors
object[]

A list of errors. Currently not used.

httpStatusCode
enum<string>

A 200 response indicates that Stedi successfully generated the X12 EDI claim format required by the payer. It does not indicate whether the payer has accepted the claim - the payer will respond later with a 277CA containing this information. Learn more about 277CAs. A 400 response indicates one or more problems with the claim data in the request. Examples include missing required fields, invalid values, or incorrect data types. The response includes a message describing the problem.

Available options:
200 OK,
400 BAD_REQUEST
meta
object

Metadata from Stedi about the request.

editStatus
string

Currently not used.

editResponses
object[]

Currently not used.

payer
object

Information about the payer for the submitted claim.

failure
object

Currently not used.