Practical examples of SOAP API data types examples for modern integrations

Instead of starting with abstract definitions, let’s walk through examples of SOAP API data types examples you actually see in production WSDLs: simple scalar values, structured complex types, arrays, enumerations, and date/time fields.

At a high level, SOAP web services lean heavily on XML Schema (XSD) data types. The best examples are usually found in public WSDLs from payment gateways, shipping carriers, and government agencies. Even in 2025, major systems in healthcare, banking, and public-sector reporting still expose SOAP endpoints, often documented with XSD-backed type definitions.

Below, each example of a SOAP API data type includes:

• A WSDL/XSD snippet showing how the type is defined
• A sample SOAP request payload using that type
• Notes on typical integration gotchas

Simple scalar types: string, int, boolean

The most common examples of SOAP API data types examples are simple scalar values. Think of login methods, ID lookups, or status flags.

Example of string and int parameters

WSDL/XSD definition:

<xs:element name="GetCustomerRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="customerId" type="xs:int"/>
      <xs:element name="countryCode" type="xs:string" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:cus="http://example.com/customer">
  <soapenv:Header/>
  <soapenv:Body>
    <cus:GetCustomerRequest>
      <cus:customerId>12345</cus:customerId>
      <cus:countryCode>US</cus:countryCode>
    </cus:GetCustomerRequest>
  </soapenv:Body>
</soapenv:Envelope>

Here you see two of the best examples of basic SOAP data types: xs:int and xs:string. Many enterprise APIs still follow this pattern for simple request/response operations.

Example of boolean flag

WSDL/XSD definition:

<xs:element name="UpdatePreferencesRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="userId" type="xs:string"/>
      <xs:element name="emailOptIn" type="xs:boolean"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request:

<upd:UpdatePreferencesRequest>
  <upd:userId>u-789</upd:userId>
  <upd:emailOptIn>true</upd:emailOptIn>
</upd:UpdatePreferencesRequest>

Boolean handling is a classic source of interop issues. Stick to true/false in lowercase, exactly as defined by XML Schema.

Complex types: structured objects with nested fields

Where SOAP gets more interesting is with examples of SOAP API data types examples that use complexType to model objects. Think of a shipping address, a patient record, or a credit card.

Example of a customer address complexType

WSDL/XSD definition:

<xs:complexType name="Address">
  <xs:sequence>
    <xs:element name="line1" type="xs:string"/>
    <xs:element name="line2" type="xs:string" minOccurs="0"/>
    <xs:element name="city" type="xs:string"/>
    <xs:element name="state" type="xs:string"/>
    <xs:element name="postalCode" type="xs:string"/>
    <xs:element name="country" type="xs:string" default="US"/>
  </xs:sequence>
</xs:complexType>

<xs:element name="CreateCustomerRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="name" type="xs:string"/>
      <xs:element name="address" type="tns:Address"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request:

<cus:CreateCustomerRequest>
  <cus:name>Jane Doe</cus:name>
  <cus:address>
    <cus:line1>123 Main St</cus:line1>
    <cus:city>Boston</cus:city>
    <cus:state>MA</cus:state>
    <cus:postalCode>02110</cus:postalCode>
    <cus:country>US</cus:country>
  </cus:address>
</cus:CreateCustomerRequest>

This is a textbook example of how SOAP models an object. In modern integrations, you’ll still see similar patterns in government tax filing services and healthcare eligibility checks, where structured address and identity data is required.

Arrays and lists: repeating elements with maxOccurs

Another set of examples of SOAP API data types examples you’ll hit constantly: lists of items. XML Schema handles this with maxOccurs and minOccurs.

Example of an array of order line items

WSDL/XSD definition:

<xs:complexType name="OrderItem">
  <xs:sequence>
    <xs:element name="sku" type="xs:string"/>
    <xs:element name="quantity" type="xs:int"/>
    <xs:element name="unitPrice" type="xs:decimal"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="Order">
  <xs:sequence>
    <xs:element name="orderId" type="xs:string"/>
    <xs:element name="items" type="tns:OrderItem" maxOccurs="unbounded"/>
  </xs:sequence>
</xs:complexType>

SOAP request:

<ord:Order>
  <ord:orderId>ORD-2025-0001</ord:orderId>
  <ord:items>
    <ord:sku>ABC-100</ord:sku>
    <ord:quantity>2</ord:quantity>
    <ord:unitPrice>19.99</ord:unitPrice>
  </ord:items>
  <ord:items>
    <ord:sku>XYZ-200</ord:sku>
    <ord:quantity>1</ord:quantity>
    <ord:unitPrice>49.50</ord:unitPrice>
  </ord:items>
</ord:Order>

Some toolkits wrap arrays in an extra container element (<items> containing multiple <item> elements). Others repeat the same element name, as above. Always check the WSDL or vendor docs; this is one of those real examples where auto-generated client code can mislead you.

Enumerations: controlled vocabularies for status and type fields

Many regulated industries use examples of SOAP API data types examples with enumerations to enforce valid values. Think of claim status, payment method, or account type.

Example of a payment method enum

WSDL/XSD definition:

<xs:simpleType name="PaymentMethod">
  <xs:restriction base="xs:string">
    <xs:enumeration value="CREDIT_CARD"/>
    <xs:enumeration value="ACH"/>
    <xs:enumeration value="WIRE"/>
  </xs:restriction>
</xs:simpleType>

<xs:element name="SubmitPaymentRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="amount" type="xs:decimal"/>
      <xs:element name="currency" type="xs:string"/>
      <xs:element name="method" type="tns:PaymentMethod"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request:

<pay:SubmitPaymentRequest>
  <pay:amount>150.00</pay:amount>
  <pay:currency>USD</pay:currency>
  <pay:method>CREDIT_CARD</pay:method>
</pay:SubmitPaymentRequest>

If you send anything other than the allowed values, you’ll usually get a schema validation error or a business-level fault. In 2024–2025, financial and healthcare SOAP APIs still rely heavily on this pattern to keep data aligned with regulatory code sets.

For a taste of how strict data vocabularies work in healthcare, check out the U.S. National Library of Medicine’s documentation on controlled vocabularies at https://www.nlm.nih.gov.

Dates and times: xs:date, xs:dateTime, and time zones

Date handling is where many real examples of SOAP API data types go off the rails. XML Schema supports xs:date, xs:time, and xs:dateTime, usually in ISO 8601 format.

Example of a scheduled appointment with xs:dateTime

WSDL/XSD definition:

<xs:element name="CreateAppointmentRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="patientId" type="xs:string"/>
      <xs:element name="scheduledAt" type="xs:dateTime"/>
      <xs:element name="timeZone" type="xs:string" minOccurs="0"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request:

<app:CreateAppointmentRequest>
  <app:patientId>PT-55421</app:patientId>
  <app:scheduledAt>2025-01-15T14:30:00-05:00</app:scheduledAt>
  <app:timeZone>America/New_York</app:timeZone>
</app:CreateAppointmentRequest>

Healthcare and scheduling systems often require precise time zone offsets. For background on date/time standards and why they matter for clinical data exchange, the Office of the National Coordinator for Health IT has helpful resources at https://www.healthit.gov.

Optional and nullable fields: minOccurs and nillable

Real integrations rarely have perfectly complete data. That’s why examples of SOAP API data types examples almost always include optional or nullable fields.

Example of optional and nillable middleName

WSDL/XSD definition:

<xs:element name="Person">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="firstName" type="xs:string"/>
      <xs:element name="middleName" type="xs:string" minOccurs="0" nillable="true"/>
      <xs:element name="lastName" type="xs:string"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

You can either omit middleName entirely, or include it explicitly as nil.

Omitted field:

<per:Person>
  <per:firstName>John</per:firstName>
  <per:lastName>Smith</per:lastName>
</per:Person>

Explicitly nil field:

<per:Person xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <per:firstName>John</per:firstName>
  <per:middleName xsi:nil="true"/>
  <per:lastName>Smith</per:lastName>
</per:Person>

This pattern shows up constantly in identity, insurance, and benefits enrollment SOAP APIs, where some demographic fields are optional but must sometimes be explicitly null.

Binary data: xs:base64Binary and attachments

Some of the more specialized examples of SOAP API data types examples involve binary content: PDFs, images, or signature blobs.

Example of a base64-encoded PDF document

WSDL/XSD definition:

<xs:element name="UploadDocumentRequest">
  <xs:complexType>
    <xs:sequence>
      <xs:element name="documentName" type="xs:string"/>
      <xs:element name="contentType" type="xs:string"/>
      <xs:element name="data" type="xs:base64Binary"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

SOAP request (truncated):

<doc:UploadDocumentRequest>
  <doc:documentName>lab-results-2025-01-10.pdf</doc:documentName>
  <doc:contentType>application/pdf</doc:contentType>
  <doc:data>
    JVBERi0xLjQKJb/3ov4KMSAwIG9iago8PC9UeXBlIC9DYXRhbG9nCi9QYWdlcyAyIDAgUgo+Pgpl
    bmRvYmoKMiAwIG9iago8PC9UeXBlIC9QYWdlcwovTWVkaWFCb3ggWzAgMCA2MTIgNzkyXQo+Pgpl
    bmRvYmoKc3RhcnR4cmVmCjM0NgolJUVPRgo=
  </doc:data>
</doc:UploadDocumentRequest>

In healthcare and government e-filing systems, this pattern is still common for submitting signed forms or supporting documentation. For broader context on secure document exchange in healthcare, the CDC provides interoperability resources at https://www.cdc.gov.

Real examples from common SOAP use cases in 2024–2025

To make these examples less abstract, let’s tie them to real-world patterns you’re likely to encounter today.

Financial services: payments and account data

Banking and payment gateways still expose SOAP APIs for legacy integrations. Typical patterns include:

• xs:decimal for currency amounts, with scale restrictions (for example, two decimal places for USD)
• Enumerated PaymentMethod and TransactionStatus types
• Complex types for Account and Beneficiary with nested address objects

These are some of the best examples of SOAP API data types examples still actively used in production. They’re heavily validated and often backed by strict XSD schemas.

Healthcare: claims, eligibility, and scheduling

In healthcare, SOAP-based standards like older HL7 web services and some payer APIs rely on:

• xs:date and xs:dateTime for admission, discharge, and service dates
• Enumerations for diagnosis codes, procedure codes, and claim status
• Complex types for Patient, Provider, and Encounter

The National Institutes of Health and related agencies document many of the underlying data standards that influence these SOAP schemas. A good starting point is https://www.nih.gov.

Government and public-sector reporting

Tax filing, environmental reporting, and regulatory submissions often use SOAP because of its strict typing and XML Schema support. Real examples include:

• Arrays of FilingRecord or ReportLine elements for batch submissions
• Base64-encoded attachments for supporting documents
• Optional fields with minOccurs="0" that reflect jurisdiction-specific requirements

These scenarios show why strong typing still matters in 2025, even as many greenfield APIs move to REST and JSON.

Putting it together: choosing the right SOAP data types

After walking through these examples of SOAP API data types examples, a few practical guidelines emerge:

• Use simple types (xs:string, xs:int, xs:boolean, xs:decimal) for scalar values like IDs, counts, and flags.
• Model real-world objects (customers, orders, appointments) as complexType with nested elements.
• Represent collections with maxOccurs="unbounded" or a specific limit, and verify how your toolkit serializes arrays.
• Use enumerations when you need controlled vocabularies, especially in regulated domains.
• Treat dates and times carefully, always in ISO 8601 format with explicit time zones when appropriate.
• Make fields optional or nillable only when the business rules truly allow missing data.
• For binary content, stick to xs:base64Binary unless both sides support more advanced attachment profiles.

If you keep these patterns in mind and refer back to the real examples above, you’ll have a solid mental model for reading any WSDL and for designing new operations that feel consistent with existing enterprise SOAP APIs.

FAQ: common questions about SOAP API data type usage

What are the most common examples of SOAP API data types?

The most common examples of SOAP API data types are simple scalar types like xs:string, xs:int, xs:boolean, and xs:decimal. Right behind them are complexType definitions used for objects such as Customer, Order, and Address, along with arrays defined using maxOccurs and enumerations for status or type fields.

Can you show an example of a SOAP array of complex types?

Yes. A typical example of a SOAP array looks like an Order that contains multiple OrderItem elements. The XSD defines OrderItem as a complexType, then sets maxOccurs="unbounded" on the items element. In the SOAP request, you repeat the <items> element for each line item, as shown in the order example earlier in this guide.

How should dates be represented in SOAP APIs?

Dates in SOAP APIs should use XML Schema types such as xs:date (for calendar dates) and xs:dateTime (for timestamps). The value is usually in ISO 8601 format, like 2025-01-15 for a date or 2025-01-15T14:30:00-05:00 for a date/time with time zone offset. Many healthcare and scheduling APIs in 2024–2025 reject non-standard date formats, so sticking to the XSD definition is important.

Are there best examples for handling optional fields in SOAP?

Good examples of handling optional fields use minOccurs="0" to make the element optional and nillable="true" when the element might appear but have no value. A classic example is a middleName field that can be omitted entirely or included with xsi:nil="true". This pattern gives you flexibility while still keeping the XML valid against the schema.

Why do some SOAP APIs still use base64 binary instead of separate file uploads?

Many older SOAP APIs were designed before modern multipart upload patterns became common. Encoding files as xs:base64Binary keeps everything inside the XML envelope and works reliably with existing toolchains. While it’s not the most efficient approach, it remains common in document-heavy workflows like claims submissions, lab result uploads, and regulatory filings.