Real-Time Eligibility Check (270/271) SOAP

Submit real-time eligibility checks over SOAP using the CAQH CORE vC2.2.0 XML Schema

POST/protocols/caqh-core

Real-time eligibility checks are ideal for in-person patient visits, telehealth appointments, and other scenarios where you need immediate information about a patient's coverage. This endpoint is ideal when you must meet CAQH Core Connectivity Safe Harbor requirements or integrate with systems requiring CAQH CORE-compliant SOAP connectivity.

Call this endpoint with a request in XML format. The XML must conform to the CAQH CORE vC2.2.0 XML Schema. The Payload element must contain a valid eligibility check in 270 X12 EDI format. We recommend reviewing the requirements for a basic eligibility request.
Stedi validates your eligibility check and sends it to the payer.
The endpoint returns a synchronous SOAP response in XML format. It contains the full 271 X12 EDI response from the payer containing the patient's eligibility and benefits information.

Test your integration with eligibility mock requests.

Headers

Name	Required	Description
`Content-Type`	Yes	Set to `application/soap+xml`.
`X-Forwarded-For`	No	(CMS requests only): Starting November 8, 2025, the Centers for Medicare & Medicaid Services (CMS) requires submitters to include network IP addresses from an eligibility request's point of origin through receipt by the HETS system. To comply with this requirement, you may need to include the `X-Forwarded-For` header in requests to CMS. When present, this header should contain a comma-separated list of upstream IP addresses, starting with the originating system and continuing through every intermediary. You can exclude your IP address from the list. Stedi blocks eligibility requests to CMS when any IP address in the chain – the originating IP address or any in the `X-Forwarded-For` header – is located outside the United States. Visit CMS traceability requirements for details and examples.

Request

The request payload must be XML that conforms to the CAQH CORE vC2.2.0 XML Schema. It consists of three main parts: the envelope, the header, and the body.

<soapenv:Envelope>
  <soapenv:Header>
    ...
  </soapenv:Header>
  <soapenv:Body>
      ...
  </soapenv:Body>
</soapenv:Envelope>

Envelope

The SOAP Envelope element wraps both the header and body. It defines the message structure according to the SOAP specification.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope" xmlns:cor="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">

Envelope must declare the following namespaces:

Namespace declaration	Required	Description
`xmlns:soapenv`	Yes	Declares the XML namespace for the SOAP envelope. Must be set to `http://www.w3.org/2003/05/soap-envelope`.
`xmlns:cor`	Yes	Declares the XML namespace for CAQH CORE rules. Must be set to `http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd`.

The Header element specifies the WS-Security namespace (wsse) and contains the required credentials for authentication.

<soapenv:Header>
  <wsse:Security soapenv:mustUnderstand="true" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">
    <wsse:UsernameToken>
      <wsse:Username>STEDI-ACCOUNT-ID</wsse:Username>
      <wsse:Password>STEDI-API-KEY</wsse:Password>
    </wsse:UsernameToken>
  </wsse:Security>
</soapenv:Header>

Header must include the following elements:

Element	Required	Description
`wsse:Security`	Yes	The parent container for the security token. It includes: The `soapenv:mustUnderstand` attribute, set to `true`. The `xmlns:wsse` namespace declaration, set to `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd` The `xmlns:wsu` namespace declaration, set to `http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd`
`wsse:Username`	Yes	Set this to your Stedi Account ID. You can find your account ID at the end of any Stedi portal URL. For example, in `https://portal.stedi.com/app/healthcare/eligibility?account=1111-33333-55555`, the account ID is `1111-33333-55555`.
`wsse:Password`	Yes	Set this to your API Key. You can create and manage API keys from the API Keys page in the Stedi portal.

Body

The Body element contains the request details, and it must conform to the CAQH CORE XML Schema vC2.2.0.

<soapenv:Body>
  <cor:COREEnvelopeRealTimeRequest>
    <PayloadType>X12_270_Request_005010X279A1</PayloadType>
    <ProcessingMode>RealTime</ProcessingMode>
    <PayloadID>YOUR-PAYLOAD-ID</PayloadID>
    <TimeStamp>2007-08-30T10:20:34.000Z</TimeStamp>
    <SenderID>SENDER-ID</SenderID>
    <ReceiverID>RECEIVER-ID</ReceiverID>
    <CORERuleVersion>2.2.0</CORERuleVersion>
    <Payload><![CDATA[ISA*00*          *00*          *ZZ*AV09311993     *01*030240928      *210101*1200*^*00501*000000001*0*P*>~GS*HS*1510848*030240928*20210101*120000*1*X*005010X279A1~ST*270*0001*005010X279A1~BHT*0022*13*00000000000000000000000000*20210101*1200~HL*1**20*1~NM1*PR*2*UnitedHealthcare*****PI*87726~HL*2*1*21*1~NM1*1P*2*Provider Name*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John****MI*UHC202649~HL*4*3*23*0~TRN*1*00000000000000000000000000*3117151744~NM1*03*1*Doe*Jane~DMG*D8*19521121~EQ*30~SE*14*0001~GE*1*1~IEA*1*000000001~]]></Payload>
  </cor:COREEnvelopeRealTimeRequest>
</soapenv:Body>

Body must include the following elements:

Element	Required	Description
`PayloadType`	Yes	The type of transaction. Must be set to `X12_270_Request_005010X279A1`.
`ProcessingMode`	Yes	The processing mode. Must be set to `RealTime`.
`PayloadID`	Yes	A unique identifier for the request. Must be a valid UUID.
`TimeStamp`	Yes	UTC time in ISO 8601 format, such as `2024-07-28T12:00:00Z`.
`SenderID`	Yes	An identifier for the transaction sender. Can be up to 50 characters. Set this to the value you plan to use in the eligibility check's `ISA06` (Interchange Sender ID) element.
`ReceiverID`	Yes	An identifier for the transaction receiver. Can be up to 50 characters. Set this to the value you plan to use in the eligibility check's `ISA08` (Interchange Receiver ID) element.
`CORERuleVersion`	Yes	The CAQH CORE rule version. Must be set to `2.2.0`.
`Payload`	Yes	The X12 EDI 270 eligibility check wrapped in `<![CDATA[ ... ]]>`. Must conform to 270 X12 EDI format. We recommend reviewing the requirements for a basic eligibility request.

Response

The HTTP response must include the following additional headers:

Header	Description	Example
`stedi-id`	A Stedi-assigned unique identifier for the eligibility check, formatted as `ec_<UUID>`. You can use this ID to track the eligibility check and deep link to its results in the Stedi portal.	`ec_f81d4fae-7dec-11d0-a765-00a0c91e6b12`
`stedi-eligibility-search-id`	A Stedi-assigned identifier that allows Stedi to group eligibility checks for the same patient into a unified record in the Stedi portal called an eligibility search.	`01997873-bebb-7b33-81ef-f408866dfb2cb`

The response body is a SOAP message, and its structure is similar to the request. The Payload element typically contains the payer's X12 EDI 271 response. However, if you send a request that fails X12 EDI validation, it will contain a 999 Implementation Acknowledgment indicating the errors.

<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope"
               xmlns:cor="http://www.caqh.org/SOAP/WSDL/CORERule2.2.0.xsd">
  <soapenv:Header/>
  <soapenv:Body>
    <cor:COREEnvelopeRealTimeResponse>
      <PayloadType>X12_271_Response_005010X279A1</PayloadType>
      <ProcessingMode>RealTime</ProcessingMode>
      <PayloadID>f81d4fae-7dec-11d0-a765-00a0c91e6b12</PayloadID>
      <TimeStamp>2025-08-06T22:23:50Z</TimeStamp>
      <SenderID>RECEIVER_ID</SenderID>
      <ReceiverID>STEDI</ReceiverID>
      <CORERuleVersion>2.2.0</CORERuleVersion>
      <Payload><![CDATA[ISA*00*          *00*          *ZZ*STEDI          *01*117151744      *260709*2201*^*00501*545482648*0*T*`~GS*HB*STEDI*117151744*20260709*220136*1*X*005010X279A1~ST*271*0001*005010X279A1~BHT*0022*11*01JDQV00485EPP4D6BD8GM1SWM*20260325*0901~HL*1**20*1~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~PER*IC**UR*WWW.UHCPROVIDER.COM~HL*2*1*21*1~NM1*1P*2*Jerde - Sauer*****XX*1999999984~HL*3*2*22*1~NM1*IL*1*Doe*John*A***MI*UHC202649~REF*6P*186084~REF*18*UVdQAC5j6f~N3*123 Sunnyvale Lane~N4*Fosterburgh*TX*91016~DMG*D8*19760214*M~DTP*291*RD8*20240101-20241231~HL*4*3*23*0~NM1*03*1*Doe*Jane*Alex~REF*18*UVdQAC5j6f~DMG*D8*19521121*F~INS*N*01*001*25~EB*1**30*C1*CHOICE PLUS*******W~DTP*636*D8*20240731~MSG*PROVIDER IS OUT NETWORK FOR MEMBER~MSG*FUNDING TYPE = SELF INSURED - LARGE GROUP~LS*2120~NM1*PR*2*UNITEDHEALTHCARE*****PI*87726~N3*P.O. BOX 30555~N4*SALT LAKE CITY*UT*841300555~PER*IC**UR*WWW.UHCPROVIDER.COM~LE*2120~EB*C*FAM*30***23*0*****Y~MSG*HIGHEST BENEFIT~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**23*0*****Y~MSG*HIGHEST BENEFIT~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***24*0*****Y~MSG*HIGHEST BENEFIT~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***29*0*****Y~MSG*HIGHEST BENEFIT~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**24*0*****Y~MSG*HIGHEST BENEFIT~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**29*0*****Y~MSG*HIGHEST BENEFIT~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***24*3200*****W~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**24*5555.16*****W~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**23*15500*****N~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**23*6850*****Y~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***23*3200*****Y~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***29*0*****Y~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***23*5000*****N~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**29*1294.84*****Y~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*G*FAM*30*C1**29*9944.84*****N~MSG*OOP MAXIMUM IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*C*FAM*30***29*1800*****N~MSG*DEDUCTIBLE IS MET WHEN FAMILY AMOUNT IS SATISFIED~EB*1**A6*********Y~MSG*HIGHEST BENEFIT~EB*1**A6*********Y~MSG*ABLETO FULLY FUNDED~EB*1**A6*********Y~MSG*ABLETO PARTIALLY FUNDED~EB*1**A6*********W~EB*A*IND*A6***27**.4****N~III*ZZ*11~EB*A*IND*A6***27**.2****Y~III*ZZ*11~EB*A*IND*A6***27**.2****Y~MSG*HIGHEST BENEFIT~III*ZZ*11~EB*A*IND*A6***27**.2****Y~MSG*ABLETO PARTIALLY FUNDED~III*ZZ*11~EB*A*IND*A6***27**0****Y~MSG*ABLETO FULLY FUNDED~III*ZZ*11~EB*B*IND*A6***27*0*****Y~MSG*HIGHEST BENEFIT~III*ZZ*11~EB*B*IND*A6***27*0*****Y~MSG*ABLETO PARTIALLY FUNDED~III*ZZ*11~EB*B*IND*A6***27*0*****W~III*ZZ*11~EB*B*IND*A6***27*0*****Y~MSG*ABLETO FULLY FUNDED~III*ZZ*11~EB*C**A6***27*0*****Y~EB*C*FAM*A6***23*0*****Y~MSG*ABLETO FULLY FUNDED~EB*F*IND*A6***27*0*****Y~MSG*ABLETO PARTIALLY FUNDED~EB*F*IND*A6***27*0*****Y~MSG*HIGHEST BENEFIT~EB*F*IND*A6***27*0*****Y~MSG*ABLETO FULLY FUNDED~EB*F*IND*A6***27*0*****Y~EB*F*IND*A6***27*0*****Y~MSG*ADDITIONAL COVERED PER OCCURRENCE~MSG*ABLETO PARTIALLY FUNDED~EB*F*IND*A6***27*0*****Y~MSG*ADDITIONAL COVERED PER OCCURRENCE~EB*F*IND*A6***27*0*****Y~MSG*ADDITIONAL COVERED PER OCCURRENCE~MSG*HIGHEST BENEFIT~EB*F*IND*A6***27*0*****Y~MSG*ADDITIONAL COVERED PER OCCURRENCE~MSG*ABLETO FULLY FUNDED~EB*X***********W~LS*2120~NM1*1P*2*NEW YORK MEDICAL BEHAVIORAL HEALTH SERVICES*****XX*1235600834~LE*2120~SE*125*0001~GE*1*1~IEA*1*545482648~]]></Payload>
      <ErrorCode>Success</ErrorCode>
      <ErrorMessage></ErrorMessage>
    </cor:COREEnvelopeRealTimeResponse>
  </soapenv:Body>
</soapenv:Envelope>

The response body includes the following elements:

Element	Description
`PayloadType`	The type of the payload returned in the response. `X12_271_Response_005010X279A1` for requests that pass X12 EDI validation. A 271 can contain benefits information for the patient or `AAA` errors. `X12_999_Response_005010X231A1` for requests that fail X12 EDI validation. `CoreEnvelopeError` when there's a Core-compliant error or Stedi couldn't parse the X12 EDI envelope.
`ProcessingMode`	The processing mode used for the request. This is always `RealTime`.
`PayloadID`	A unique identifier Stedi generated for the transaction. This won't be the same value you submitted as the `PayloadID` in the request.
`TimeStamp`	The timestamp when the response was generated in ISO 8601 format.
`SenderID`	The ID of the sender of the response. This is always the same as the `ReceiverID` in the request.
`ReceiverID`	The ID of the receiver of the response. This is always the same as the `SenderID` in the request.
`CORERuleVersion`	The CAQH CORE rule version. This is always `2.2.0`.
`Payload`	The X12 EDI response. 271 Eligibility Benefit Response for requests that pass X12 EDI validation. A 271 can contain benefits information for the patient or `AAA` errors. 999 Implementation Acknowledgment when the request fails X12 EDI validation. Empty when the request fails due to a CORE-compliant error or because Stedi couldn't parse the X12 EDI envelope.
`ErrorCode`	The error code, if any, associated with the response. These errors typically indicate issues with the request body, such as missing or invalid elements. They can also indicate authentication issues and other processing errors. Learn more.
`ErrorMessage`	A description of the error, if any.
`Fault`	Only included when there is a SOAP fault. It includes a `Code` and `Reason` element that describe the error.

HTTP status codes

Most errors return SOAP, but some return JSON containing the HTTP status code and a brief message describing the error.

Status Code	Response	Description
`200 OK`	SOAP	Indicates a successful request. Note that Stedi returns a `200` even when the payer returns `AAA` errors in the 271 response.
`400 Bad Request`	SOAP	Indicates a SOAP fault, an error with the SOAP request body, or an X12 EDI validation error.
`401 Unauthorized`	SOAP	Indicates issues with the Stedi account ID or API key you provided. Example
`404 Not Found`	JSON	Indicates that the specified endpoint doesn't exist. Verify that you are using the correct URL for this endpoint: `https://healthcare.us.stedi.com/2025-06-01/protocols/caqh-core`.
`429 Too Many Requests`	SOAP	Indicates that you have exceeded your concurrency limit for this endpoint. The X12 response will contain an `AAA` error with code `42`. Stedi will continue rejecting additional requests with a `429` status code until one of your previous requests is completed. Example
`500 Internal Server Error`	JSON	Indicates an unexpected error on Stedi's side. If you encounter this error, please contact Stedi Support for assistance.