A WireMock simulation of U.S. Bank's REST API — covering driver, vehicle, pool, and list management for fleet card programs.
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://y0zgv.wiremockapi.cloud/vehicles' \
-H 'Content-Type: application/json' \
-d '{}'PATCH Update vehicle
curl -s -X PATCH 'https://y0zgv.wiremockapi.cloud/vehicles/your-vehicleID' \
-H 'Content-Type: application/json' \
-d '{}'DELETE Delete list
curl -s -X DELETE 'https://y0zgv.wiremockapi.cloud/lists/your-listID'Spec catalog — One Card for Fleet (1.0.0) · 17 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /drivers | Create a new driver record. |
| GET | /drivers/{driverID} | Read a driver record. |
| PATCH | /drivers/{driverID} | Modify a driver record. |
| POST | /drivers/search | Find drivers matching the search criteria. |
| POST | /lists | Create a new list of drivers or vehicles. |
| DELETE | /lists/{listID} | Delete a list record. |
| GET | /lists/{listID} | Read a list record. |
| PATCH | /lists/{listID} | Modify a list record. |
| POST | /lists/search | Find lists matching the search criteria. |
| POST | /pools | Create a new pool record. |
| GET | /pools/{poolID} | Read a pool record. |
| PATCH | /pools/{poolID} | Modify a pool record. |
| POST | /pools/search | Find pools matching the search criteria. |
| POST | /vehicles | Create a new vehicle record. |
| GET | /vehicles/{vehicleID} | Read a vehicle record. |
| PATCH | /vehicles/{vehicleID} | Modify a vehicle record. |
| POST | /vehicles/search | Find vehicles matching the search criteria. |
Unauthenticated WireMock Cloud demo sandbox for U.S. Bank — not an official U.S. Bank sandbox, and it returns simulated example data only.
Of the U.S. Bank sandboxes, this one behaves most like a database. All four record types — drivers, vehicles, pools, lists — share the same living contract: create returns the fields you submitted plus a minted six-digit ID, the ID dereferences on the read route, PATCH merges new field values into the stored record, and the search routes report the store's actual contents, growing as records are added. Ids with no record behind them draw the numbered resource-not-found envelope. The result is a mock where a full onboarding sequence — enroll a driver, register a vehicle, group them, verify by search — runs end to end with every step's effect observable in the next.
They survive. PATCH answers 204, and re-reading the record shows the changed field merged alongside everything else you originally submitted. That closes the loop most mocks leave open: an edit form's save-then-refresh cycle can be tested against the sandbox with genuine before-and-after assertions.
Because the spec draws the same line — lists are disposable groupings, while drivers, vehicles, and pools deactivate rather than disappear. The mock honors it: DELETE on a list returns 204 and subsequent reads 404, but the other three types have no delete route at all. Records you mint therefore stay in the shared store until it resets, so give test data throwaway names and key assertions on the ids you minted rather than on totals.
Directly useful — a driver created a moment ago appears in the next driver search, submitted fields intact. Note the flip side: because every visitor's records land in the same roster, search results are shared-world data. Assert that your record is present, never that it is alone.
Whatever you put there. The store is schema-light and echoes the attributes you send — useful for driving your own client models through serialization round-trips, and a reminder that the sandbox won't police required fields or formats the way the production gateway's validation will.
Same fleet domain, different card platform and different API grammar — One Card is RESTful with ids in paths, while the Voyager Cards template and its siblings do everything by POST with body-carried keys. Teams migrating between the two programs can run both mocks side by side and diff their client code against each idiom.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.