Loading…
Loading…
The Consume direction modernizes your backend while keeping legacy SOAP clients working unchanged.
The Consume direction modernizes your backend while keeping legacy SOAP clients working unchanged. The platform acts as a SOAP facade: it ingests SOAP envelopes from existing consumers, converts each call to a REST request against your migrated REST backend, and wraps the REST response back into a SOAP envelope. The consumer keeps speaking SOAP; the backend is REST.
This is the inverse of the Publish direction. Both run on the same runtime; the direction is fixed per service.
Use Consume when you have migrated a service to REST but cannot (yet) migrate the SOAP clients that call it — for example a legacy partner, an internal app you don't control, or a phased migration. The SOAP facade lets the backend move to REST today without a coordinated client cutover.
A safe SOAP↔REST mapping needs more than the two contracts: the REST publisher may have renamed fields, reshaped wrappers, or changed semantics relative to the legacy SOAP contract, so a contract-only auto-mapping can silently produce wrong values. The Consume wizard therefore requires four inputs before a service is publish-ready, supplied in order:
The mapping engine synthesizes the bidirectional mapping from WSDL + OpenAPI grounded by the examples — the examples resolve ambiguity the two contracts alone cannot capture. The wizard exposes the steps in this order:
Service identity → Old WSDL → REST OpenAPI → REST backend config (incl. auth)
→ Example payloads → Mapping review → Publish
A Consume service will not publish until all four inputs are present.
Because the consumer-facing wire format is SOAP, the published contract is a WSDL, not
OpenAPI. The platform serves the contract back at the consume endpoint, with the
<soap:address location="..."> pointing at the canonical direction-prefixed runtime route so
generated SOAP clients hit the right path. The inbound-WSDL download is available at both the
draft and the published stages, mirroring the OpenAPI-export affordance on Publish services.
A Consume service does not get a generated OpenAPI document — pointing consumers at one would misrepresent the contract (a REST spec at a URL that accepts SOAP). See Generate & review the OpenAPI.
Since v1.0 the inbound SOAP listener accepts both SOAP versions:
text/xml, faultcode/faultstring/detail fault model, SOAPAction header.application/soap+xml, two-level fault model.The runtime detects the version from the request body and content type. The operation is
resolved by message QName and SOAPAction, cross-checked against the path's serviceKey and
operationPath. Faults generated on the inbound side use the matching SOAP version's fault shape.
Out of scope at v1.0: WS-Security message signing/encryption on the inbound SOAP-facade path. See SOAP & XSD support → out of scope.
The outbound call to your migrated REST backend supports the same auth types as a Publish backend profile (see Configure the backend):
| Auth type | Use it for |
|---|---|
| none | Unauthenticated backend in a trusted segment. |
| basic | HTTP Basic. |
| bearer | Static / externally-provisioned bearer token. |
| oauth2_client_credentials | OAuth2 client-credentials — the runtime mints and caches the token. |
| api_key_header | API key in a named header. |
| mTLS | Mutual TLS client certificate, composable alongside any of the above. |
Credentials are encrypted at rest and never logged or returned in plaintext.
Like Publish, every Consume invocation uses the direction-prefixed path:
/consume/{environment}/{serviceKey}/{operationPath...}
The direction segment is required; a path without it is rejected with HTTP 400. See Onboarding overview → Runtime URL shape.