A WireMock simulation of U.S. Bank's REST API — covering vehicle registration, detail reads, roster search, temporary limits, and lifecycle status moves.
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 Create vehicle
curl -s -X POST 'https://7md03.wiremockapi.cloud/vehicles' \
-H 'Content-Type: application/json' \
-d '{}'PUT Update temp limits
curl -s -X PUT 'https://7md03.wiremockapi.cloud/vehicles/temp-limits/update' \
-H 'Content-Type: application/json' \
-d '{}'POST Get vehicle by vehicleID
curl -s -X POST 'https://7md03.wiremockapi.cloud/vehicles/read' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Voyager Account Management - Vehicles (1.4.0) · 9 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /vehicles | Create a vehicle. |
| POST | /vehicles/reactivate | Reactivate a terminated vehicle. |
| POST | /vehicles/read | Return details of a vehicle. |
| POST | /vehicles/search | Search for vehicles. |
| POST | /vehicles/temp-limits/delete | Delete vehicle temporary limits. |
| POST | /vehicles/temp-limits/read | Read vehicle temporary limits. |
| PUT | /vehicles/temp-limits/update | Update vehicle temporary limits. |
| POST | /vehicles/terminate | Terminate an active vehicle. |
| POST | /vehicles/update | Update a vehicle. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
Vehicle registration in this sandbox is bring-your-own-id: the create route reflects the top-level accountID and vehicleID fields of your request and files the vehicle under the id you supplied, so the very next body-keyed read resolves it. That inverts the convention its sibling templates follow and makes this the Voyager surface where test fixtures can use stable, human-readable ids — register vehicle 999888 in a setup step and every later assertion knows its key in advance. Leave vehicleID out and the echo comes back as empty strings with nothing filed; wrap the fields in a nested vehicle object and they are not read at all. The search roster, meanwhile, carries its own fixture vehicle, 123456, active on the ACME fleet account.
The request fields weren't where the stub looks. Only top-level accountID and vehicleID are reflected and registered; a body shaped as vehicle-object-with-properties passes through without being read, and the response's empty strings are the tell. Flatten the two fields to the root of the JSON and the same call both echoes and files the vehicle.
Yes, if the id came through a create in this sandbox — the store keys on what registration filed, and unknown ids draw the vehicle-does-not-exist error with its numbered code. The one id that predictably fails is 123456: the search fixture advertises it, but no create ever filed it, so list-then-detail journeys break at the detail step unless a private copy stitches the two together.
Same grammar, opposite id policy. The Voyager Drivers sandbox keeps id assignment on the server and ignores what clients propose; vehicles accept the client's id verbatim. Exercising both teaches an integration to survive either convention — worth doing, because the production processor decides per resource type, not per API.
Contract-for-contract, yes: the temporary-limits read serves the familiar weekday-window fixture, and update, delete, terminate, and reactivate all acknowledge with 204 regardless of the id quoted. What that buys you is verb and payload verification across the whole vehicle lifecycle; observable state transitions stay the card store's specialty in the Voyager Cards template.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.