A WireMock simulation of U.S. Bank's REST API — covering driver enrollment, body-keyed reads and searches, temporary spending limits, and termination and reactivation.
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 driver
curl -s -X POST 'https://98wk4.wiremockapi.cloud/drivers' \
-H 'Content-Type: application/json' \
-d '{}'PUT Update temp limits
curl -s -X PUT 'https://98wk4.wiremockapi.cloud/drivers/temp-limits/update' \
-H 'Content-Type: application/json' \
-d '{}'POST Update driver
curl -s -X POST 'https://98wk4.wiremockapi.cloud/drivers/update' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — Voyager Account Management - Drivers (1.5.0) · 9 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /drivers | Create a driver. |
| POST | /drivers/reactivate | Reactivate a terminated driver. |
| POST | /drivers/read | Return details of a driver. |
| POST | /drivers/search | Search for drivers. |
| POST | /drivers/temp-limits/delete | Delete driver temporary limits. |
| POST | /drivers/temp-limits/read | Read driver temporary limits. |
| PUT | /drivers/temp-limits/update | Update driver temporary limits. |
| POST | /drivers/terminate | Terminate an active driver. |
| POST | /drivers/update | Update a driver. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
Enrolling a driver here means accepting a number the bank chooses: every POST to /drivers hands back a fresh six-digit driver number, and a driverID you write into the request body is discarded in favor of the server's pick. The read route honors exactly the numbers this sandbox has assigned — quote one back and the driver envelope returns, quote anything else and the driver-does-not-exist error answers. Around that contract sit the fixtures: a search that reports driver 012345 active on fleet account 876543210, and a temporary-limits read whose transaction ceilings step from 22 a day through 333 a week to 4,444 a month — values chosen so a mapping bug between periods shows up as a wrong number, not a coincidence.
Not in this template — creation always assigns the number server-side, which mirrors how the Voyager processor issues driver credentials. Deterministic ids are available one template over: the Voyager Vehicles sandbox registers whatever vehicleID your request carries, so suites that need stable keys can lean on vehicles while driver flows work with captured mints.
A fixture one — 012345, active on account 876543210 — that the read route has never heard of. Enrollment and discovery run on different data on purpose, so a client that lists drivers and then fetches each row's detail will hit the error path on its first click-through. Wire that join in a private WireMock Cloud copy; against the public sandbox, verify detail reads with numbers you just enrolled.
Nothing observable — both answer 204 whether or not the driver number was ever assigned, and a subsequent read reports the same envelope as before. They pin down the request contract for offboarding flows; asserting that a terminated driver reads back as inactive requires stubbing that transition yourself.
Because unmistakable values make crossed wires visible. Daily, weekly, monthly, and cycle ceilings that all said 1000 would let a day-for-month swap pass silently; tiers that differ by an order of magnitude fail loudly the moment a renderer or validator binds the wrong period. The dollar amounts do sit at a uniform $1,000, so the count tiers are where mapping assertions belong.
Cards are issued and serviced in the Voyager Cards template, and account structure sits in the Voyager Accounts template — this template only owns the people. All three speak the same POST-carried-body dialect, so client plumbing built for one transfers to the others unchanged.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.