Mock a SOAP API online, free — a hosted SOAP mock endpoint in two curls

SOAP never died — it just moved into banks, insurers, logistics carriers, payment switches and government gateways, where your integration code still has to speak text/xml envelopes. What did die is convenience: nearly every SOAP mocking tool is something you install and run yourself — SoapUI mock services on your desktop, Castlemock or WireMock on a server you maintain. When all you need is a URL that answers my SOAP call with a canned envelope so I can build and test the client, that's a lot of ceremony.

Mockbird's custom routes serve any content-type, including XML. That gives you a hosted SOAP stub in about 60 seconds: your exact response envelope, real SOAP faults on HTTP 500, artificial delays for timeout testing, and a request inspector that captures the SOAPAction header and the incoming XML body. No install, no signup.

1. A SOAP mock in 60 seconds

Create a project (anonymous, one curl — save the adminKey):

curl -s -X POST https://mockbird.mockbird.workers.dev/api/projects \
  -H 'content-type: application/json' -d '{"name":"soap-stub"}'
# → {"id":"YOUR_ID","adminKey":"...","baseUrl":"https://mockbird.mockbird.workers.dev/m/YOUR_ID", ...}

Add a route that answers a GetQuote operation with a templated envelope ({{now}} and {{uuid}} are rendered per request):

curl -s -X POST https://mockbird.mockbird.workers.dev/api/projects/YOUR_ID/routes \
  -H 'x-admin-key: YOUR_ADMIN_KEY' -H 'content-type: application/json' -d '{
  "method": "POST",
  "path": "/soap/quote",
  "contentType": "text/xml; charset=utf-8",
  "body": "<?xml version=\"1.0\"?>\n<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n  <soap:Body>\n    <GetQuoteResponse xmlns=\"http://example.com/stock\">\n      <Symbol>ACME</Symbol>\n      <Price>132.85</Price>\n      <Currency>USD</Currency>\n      <AsOf>{{now}}</AsOf>\n      <RequestId>{{uuid}}</RequestId>\n    </GetQuoteResponse>\n  </soap:Body>\n</soap:Envelope>"
}'

Call it exactly like the real service — SOAPAction header, XML request body:

curl -s -X POST https://mockbird.mockbird.workers.dev/m/YOUR_ID/soap/quote \
  -H 'Content-Type: text/xml; charset=utf-8' \
  -H 'SOAPAction: "http://example.com/stock/GetQuote"' \
  --data '<?xml version="1.0"?><soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><GetQuote xmlns="http://example.com/stock"><Symbol>ACME</Symbol></GetQuote></soap:Body></soap:Envelope>'

Response: HTTP 200, content-type: text/xml; charset=utf-8, your envelope with a fresh timestamp and request id. SOAP 1.2 clients work the same way — routes don't care whether the request says text/xml or application/soap+xml, and you control the response content-type per route.

2. SOAP faults (the part everyone forgets to test)

Per SOAP 1.1, faults ride on HTTP 500 with a <soap:Fault> envelope. Make a dedicated fault route and point your client's unhappy-path tests at it:

curl -s -X POST https://mockbird.mockbird.workers.dev/api/projects/YOUR_ID/routes \
  -H 'x-admin-key: YOUR_ADMIN_KEY' -H 'content-type: application/json' -d '{
  "method": "POST",
  "path": "/soap/fault",
  "status": 500,
  "contentType": "text/xml; charset=utf-8",
  "body": "<?xml version=\"1.0\"?>\n<soap:Envelope xmlns:soap=\"http://schemas.xmlsoap.org/soap/envelope/\">\n  <soap:Body>\n    <soap:Fault>\n      <faultcode>soap:Server</faultcode>\n      <faultstring>Simulated backend failure</faultstring>\n    </soap:Fault>\n  </soap:Body>\n</soap:Envelope>"
}'

For timeout handling, add ?mock_delay=3000 (milliseconds, up to 5000) to any call — the route answers after the delay, so you can verify your client's read-timeout and retry behavior against a URL that's deliberately slow:

curl -s -X POST 'https://mockbird.mockbird.workers.dev/m/YOUR_ID/soap/quote?mock_delay=3000' \
  -H 'Content-Type: text/xml' --data '<x/>'   # answers after ~3s

Honest detail: ?mock_status=503 also works on these routes, but its body is Mockbird's JSON error — fine when your client only branches on the HTTP status, wrong if it parses the body expecting a fault envelope. When the body matters, use a dedicated fault route like the one above (you can make one per faultcode).

3. Real SOAP services have one endpoint — two ways to model that

Classic SOAP exposes a single URL; operations are distinguished by the SOAPAction header or the body's root element, not the path. Mockbird routes are path-based, so pick whichever of these fits:

• One route per operation path (shown above) — cleanest when you control the endpoint URL your client uses in tests, which is almost always true (it's a constructor argument or config value in every SOAP client).
• One catch-all route — a trailing-* path answers every POST under it with the same envelope, whatever the operation:

  {"method":"POST","path":"/onesvc/*","contentType":"text/xml; charset=utf-8","body":"..."}

  POST /m/YOUR_ID/onesvc/anything/here all land on it.

Either way, the request inspector logs the last 50 calls with the SOAPAction header and the XML request body captured — so when your client sends the wrong action or a mangled envelope, you can actually see it:

curl -s https://mockbird.mockbird.workers.dev/api/projects/YOUR_ID/requests \
  -H 'x-admin-key: YOUR_ADMIN_KEY'

4. Serving a WSDL

If your client insists on fetching a WSDL first (zeep does; many others accept a plain endpoint URL instead), host it as another route — paste your real WSDL as the body:

{"method":"GET","path":"/soap/quote.wsdl","contentType":"text/xml; charset=utf-8","body":"<definitions ...your WSDL...>"}

Point the soap:address location inside it at your mock URL and the client will call the mock. Mockbird does not parse or generate WSDLs — you bring your own (see the honest comparison below).

5. Honest comparison

Plainly: if you need full contract-faithful mocking of a big WSDL with per-operation dispatch on one endpoint, SoapUI or Castlemock is the right tool — that's what WSDL import is for. Mockbird wins the other case: you're writing or testing a SOAP client, you know the two or three envelopes you care about, and you want a stable hosted URL in the next minute — from CI, a teammate's laptop, or a no-code tool — without installing or hosting anything.

This page is written by the Mockbird maker — bias disclosed. Every command above was run verbatim against production before publishing (templated envelope, fault route, 3s delay, catch-all, inspector capture). Anonymous projects have a per-IP daily creation cap; sign up (free) to keep projects permanently.

Full API reference in the docs. More guides: mock any endpoint · mock a third-party API · testing loading & error states. Create your API →