A WireMock simulation of U.S. Bank's REST API — covering fleet transaction search across accounts and organizations.
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 Find transactions
curl -s -X POST 'https://g8zv9.wiremockapi.cloud/transactions/search' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Voyager Transactions (2.4.0) · 1 endpoint
| Method | Path | Summary |
|---|---|---|
| POST | /transactions/search | Find transactions within an account or organization. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
This is the reporting end of the Voyager fleet family: a single search route where criteria travel in the request body, and every query resolves to the day's specimen — a completed fuel purchase, $27.64 at an inside electronic terminal, full service, captured with the odometer at 120,000. The row shows why fleet cards report differently than ordinary card feeds: alongside the money sit the operational fields — service type, sale-type description, invoice number, a user-defined card code — and a three-part timeline of transaction date, transaction time, and a posting date that lands the following day. The page metadata agrees with itself, one result on one page of one, so result-count logic gets an honest baseline.
Filtering isn't evaluated — account numbers, organization numbers, and date windows are all accepted, and the same single-row page answers. The public sandbox proves your request reaches the route in the shape the spec wants and your parser handles the response; whether a date window actually narrows results is behavior to model in a private WireMock Cloud copy with one stub per criteria case.
The capture data. An odometer reading, a full-versus-self service flag, and a sale-type description are pump-side facts that only exist because a fleet card collected them at the point of sale — they're the raw material for fuel-economy reporting and misuse detection, and mapping them correctly is most of what a Voyager integration is for. Generic card-feed models will drop these fields silently; this fixture is where that loss becomes visible.
Two adjacent code fields, three possible presences — populated, empty, absent — and this row supplies the awkward middle one. An empty string is neither a missing key nor a usable value, and display code that prints it, dedupe logic that keys on it, or validation that conflates it with null each behave differently. The fixture puts that decision in front of you on the first response.
Each noun in this row has its own template. The cards that made the purchase are issued and serviced in the Voyager Cards template, the people driving are enrolled in the Voyager Drivers template, and the trucks with the odometers are registered in the Voyager Vehicles template. Transactions are where those three meet, so integration tests often finish here after exercising the others.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.