SOAP vs REST APIs in Carrier Integration

If someone hands you a .wsdl file and asks you to generate a client, you're dealing with SOAP. If they hand you an OpenAPI spec and a bearer token, you're dealing with REST. That's the practical difference most integration teams care about, but it's worth being precise: SOAP is a strict, XML-based messaging protocol with a formal contract, while REST is an architectural style that uses standard HTTP verbs and typically, though not strictly, exchanges JSON. Understanding this SOAP vs REST API distinction matters right now because FedEx, USPS and others are forcing shippers off the old protocol on a hard deadline.

SOAP API explained, and where it differs from REST

SOAP (Simple Object Access Protocol) defines a rigid envelope structure for every message, describes every operation in a WSDL file, and historically shipped over HTTP but can technically run over other transports like SMTP. REST has no equivalent single specification. It's a set of constraints (stateless requests, resource-based URLs, standard HTTP methods) that happens to pair naturally with JSON, but a REST API returning XML is still a REST API by definition. This is the first confusion to clear up: "REST API" and "JSON API" get used interchangeably, but they aren't strictly synonyms.

How to tell which one a carrier has actually given you

You don't need to read the carrier's developer portal copy to know what you're integrating with. Look at the artefacts they send you.

Older carrier systems tend to be SOAP, which means WSDL-generated clients and manual XML parsing on your side. Newer builds tend to be REST-only. GLS's group-wide ShipIT web services are documented as both REST and SOAP, so the same carrier group can hand different national units different protocols depending on when that unit's integration was built.

Why SOAP got built in the first place, and why it's being retired now

SOAP won the enterprise integration wars of the 2000s because of strict typing and a formal contract that large IT departments trusted. REST overtook it over the following decade because it's lighter to implement, easier to version, and doesn't require generating client code from a schema every time something changes. Carriers are now actively walking away from SOAP on fixed dates rather than letting it fade out.

On 30 January 2026, FedEx issued a clear deadline: all integrations must migrate from FedEx Web Services to FedEx REST APIs, with Compatible Providers required to complete upgrades by 31 March 2026 and end customers by 1 June 2026. This isn't a FedEx-only move. The USPS Web Tools API platform was retired on January 25, 2026, which was the older XML-based protocol that many European 3PLs and marketplace integrations relied on for US-bound mail. Two major carriers retiring their legacy XML stacks within five weeks of each other is the signal worth paying attention to, not an isolated FedEx decision.

Worked example: FedEx Web Services becoming FedEx REST APIs

This is the clearest case study available right now, because the retirement is documented down to the field level. FedEx's SOAP and plain XML web services were defined in WSDL files containing schemas that describe the layout of every operation, and developers had to obtain a test account number, test meter number, authentication key and password before they could even run a request against FedEx's test servers. That's four separate static credentials your system had to store and send with every call, and FedEx Web Services used what it called four-factor authentication, requiring the account number used to generate the credentials to be sent along with them. The replacement flips that model entirely. Both carriers are moving to a RESTful API using OAuth 2.0 instead of single access key authentication, which means instead of a password that never expires, your system now requests a short-lived bearer token and has to refresh it on a schedule. That single change, replacing a static key with a token your code has to actively manage, is the part integration teams underestimate most. It's not a find-and-replace on the endpoint URL. Existing SOAP calls don't map one-to-one to REST endpoints, since rate shopping, label generation and tracking require new endpoint structures, different request formatting, and JSON payloads with different field names, nesting structures and data types than the original SOAP XML.

Why this matters when you run more than one carrier

A European shipper running DHL, GLS, PostNL and FedEx side by side is, right now, juggling multiple points on the SOAP-to-REST spectrum simultaneously. One carrier might still run a WSDL-based SOAP service for one country unit while another national branch of the same group has already gone REST-only, which is exactly the situation inside GLS's own group-wide infrastructure. Your team ends up maintaining a WSDL-generated client for one connection and a JSON SDK with OAuth token refresh logic for another, on top of whatever EDI-over-AS2 file transfers you're still running for larger freight partners.

This protocol fragmentation is precisely the problem multi-carrier connectivity layers exist to solve. Platforms like Cargoson, nShift, Shiptify and EasyPost sit between your TMS or ERP and each carrier's native protocol, whatever it happens to be, and normalize it into one consistent interface on your side. You stop hand-maintaining a SOAP client for one carrier and a REST client for the next every time one of them announces a retirement date.

Common mistakes during a SOAP-to-REST migration

• Assuming SOAP Fault codes map cleanly onto REST HTTP status codes. They don't, and retry logic built around the old error structure can misfire, treating a permanent failure as temporary and hammering the new endpoint until you get rate-limited.
• Forgetting that static credentials and OAuth tokens behave completely differently. A key and password never expire mid-session; an OAuth bearer token does, and your integration needs refresh logic that didn't exist before.
• Treating the migration as a URL swap rather than a rebuild. The WSDL retirement means the entire request and response parsing layer changes, not just where you send the call.

FAQ

Is SOAP dead? Not everywhere yet. Carriers retire it on their own timelines, and some national units still run it as a legacy option even after promoting a REST alternative elsewhere in the same group.

Does REST always mean JSON? No. REST is an architectural style, not a data format requirement, though JSON is by far the common pairing you'll see from carriers today.

Can my system support both protocols during a transition? Yes, and running both in parallel temporarily while you validate the new REST responses against known SOAP outputs is the safer way to cut over than a hard switch on deadline day.

Is GraphQL a type of REST? No. GraphQL is its own query language and runtime, distinct from REST's resource-per-URL convention, even though both typically run over HTTP with JSON.

Does EDI over AS2 use SOAP or REST? Neither. AS2 is a file-transfer mechanism for exchanging EDI documents like transport orders, separate from either API style, and carriers that still rely on EDI aren't affected by a SOAP-to-REST API migration at all.