A WireMock simulation of U.S. Bank's REST API — covering routing-number validation with bank, branch, and transfer-mode detail.
A shared instance of this template runs on a public endpoint — call it right now from curl, an SDK, or an AI agent. Responses are fixed examples and behavior can't be changed; rate limits apply.
Jump to the endpoints ↓Run this template as a mock API in WireMock Cloud for a private instance you control — edit stubs, add stateful scenarios, use dynamic response templating, and inspect requests in the log.
Open in WireMock Cloud (free) →Live sandbox · no signup, no API key
A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.
Endpoints
POST Domestic routing number lookup
curl -s -X POST 'https://05qdy.wiremockapi.cloud/bankDetails/domestic' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Bank Information (1.1.0) · 1 endpoint
| Method | Path | Summary |
|---|---|---|
| POST | /bankDetails/domestic | Validate RTN and fetch bank,branch details and supported modes of transfer for a given routing number. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
One route, built for batches: the API takes an array of routing numbers and answers per number, and the fixture demonstrates both possible fates in a single response. Routing number 091000022 — U.S. Bank's own Minneapolis RTN — resolves to a Match Found carrying the full institutional identity: bank name, branch, street address, and the four transfer rails the bank can receive on (ACH, RTP, wire, and FedNow). Its neighbor in the results, the deliberately invalid 123456789, reports Match Not Found with an explanatory message and no bank block at all. A results renderer, a rail-eligibility decision, and a missing-data guard all get exercised by one call.
No — whatever array you send, the inquiry always reports on the two fixture numbers, and your submitted values are never echoed back. That makes the sandbox a response-side contract: point your client at it to verify parsing, result iteration, and the per-number status handling. Request-side behavior — one result row per submitted RTN, in order — is what a private WireMock Cloud copy with templated stubs adds.
Because "we looked and it doesn't exist" is a successful lookup. The inquiryStatus block counts requests the service could process, and a not-found verdict is a processed request — unsuccessfulRequestCount is reserved for entries the service couldn't evaluate at all. Clients that equate not-found with failure will misread this API; the per-result status field is where the real answer lives.
Rail-selection logic. The resolved bank advertises ACH, RTP, WIRE, and FedNow all at once — a fully reachable institution — so every branch of a "which network do we use" decision tree can fire. The natural companion is the PaySmart template, whose transfers actually cascade across those rails: validate the destination here, then watch the delivery-method choice play out there.
Different question, different template. A routing number tells you the institution exists and which rails reach it; whether a specific account at that institution is open, in good standing, and owned by the person you're about to pay is the Account Validation template's territory. Pre-payment verification flows typically chain the two checks in that order.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.