What is a web service?

A plain-language guide for developers who have worked with REST APIs and are encountering SOAP/XML web services for the first time.

Software talking to software over the internet

A web service is a standardized way for two programs to exchange data over the internet. You send a structured request; the remote service processes it and returns a structured response. The communication follows a published contract so both sides agree on the shape of every message.

If you have worked with REST APIs, you already know the core concept: your code sends an HTTP request and receives data back. Web services work the same way at the network level, but they use a different protocol, a different data format, and a different way of naming what you want the service to do. Those differences are what this page explains.

These are SOAP/XML web services, not REST

REST APIs use multiple HTTP verbs (GET, POST, PUT, DELETE) and distinct URL paths to represent resources (/orders/42, /shipments). Request and response bodies are almost always JSON.

SOAP web services work differently on every one of those points:

1Single endpoint, always POST. Every call goes to the same URL via HTTP POST. There is no "GET /resources/entry/42" — there is just one endpoint and you tell it which operation you want inside the request body.
2XML, not JSON. The request body and the response body are both XML documents. There are no JSON fields; everything is expressed as nested XML elements with attribute names defined by the schema.
3Named operations. Instead of a URL path like /entries, you invoke a named operation (for example, uploadEntry). The service's WSDL document lists every operation and the XML structure it expects. On a service page, the Available operations section lists these for you.

In practice that means your HTTP client sends a POST to the service URL with an XML body, and receives an XML response. Any HTTP library can do this — the envelope format is the only new piece.

What is XML?

XML (eXtensible Markup Language) represents structured data as nested tags, similar in appearance to HTML. If you have written HTML, the syntax will look familiar — but XML has no predefined tags. The names of the elements are defined by the schema for each service.

A small JSON object and its XML equivalent illustrate the difference:

JSON

{
  "shipment": {
    "entryNumber": "ABC-1234567",
    "importerName": "Acme Corp"
  }
}

XML equivalent

<shipment>
  <entryNumber>
    ABC-1234567
  </entryNumber>
  <importerName>
    Acme Corp
  </importerName>
</shipment>

Values sit between an opening tag (<entryNumber>) and a closing tag (</entryNumber>). Elements can be nested to any depth, and they can repeat — for instance, a shipment with multiple line items contains several consecutive <lineItem> elements.

The field reference on each service page documents every element the service accepts: its data type, whether it is required or optional, whether it can repeat, any length or pattern constraints, and allowed enumeration values.

How to read a Strix web service page

Each service page follows the same layout:

1.Overview — a summary of what the service does, where it fits in the customs workflow, and any version or format notes from the schema.
2.Available operations — the named operations the service exposes (for example, uploadEntry or queryStatus). Each entry lists the operation name and the parameters it accepts.
3.Example request / Example responses — a complete, realistic XML sample you can use as a starting template. Copy it with the button, replace the placeholder values with your data, and send it to the endpoint.
4.Field reference — a searchable, nested list of every element. Use the search bar to jump to a specific field by name, or browse the tree on the left. Each card shows plain-language cardinality (Required, Optional, Repeatable) and, under "Technical details," the XSD type and any value constraints.

The left-hand tree mirrors the nesting of the XML document. If a field is nested three levels deep in the tree, its XML element is three levels deep inside the request body.

Getting connected

To call any of these services you need two things that Strix issues on a per-account basis:

The fully qualified service URL — the specific HTTPS endpoint your account is authorized to call. This is not published in the documentation.
Credentials — the username and password (or token) passed in the request headers or SOAP envelope to authenticate your account.

These are provisioned when you set up integration with Strix. If you have not received them, or if you are evaluating whether to integrate, reach out to us directly.

Contact Strix (406) 922-6600

All web services All web services