A WireMock simulation of U.S. Bank's REST API — covering SCIM 2.0 user provisioning, schema discovery, customer organizations, approval policies, and user roles.
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 SCIM user
curl -s -X POST 'https://6g801.wiremockapi.cloud/scim/v2/Users' \
-H 'Content-Type: application/json' \
-d '{}'GET List resource types
curl -s -X GET 'https://6g801.wiremockapi.cloud/scim/v2/ResourceTypes'GET Get resource type
curl -s -X GET 'https://6g801.wiremockapi.cloud/scim/v2/ResourceTypes/your-resourceTypeID'Spec catalog — Freight Payment Customer Profiles (1.1.1) · 12 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /organizations | Retrieve customer organizations. |
| GET | /organizations/{organizationID}/approval-policy-levels | Retrieve approval policy levels. |
| GET | /scim/v2/ResourceTypes | List Resources. |
| GET | /scim/v2/ResourceTypes/{resourceTypeID} | Get a Resource. |
| GET | /scim/v2/Schemas | List Schemas. |
| GET | /scim/v2/Schemas/{schemaID} | Get a Schema. |
| GET | /scim/v2/ServiceProviderConfig | Get the Service Provider Configuration. |
| GET | /scim/v2/Users | List Users. |
| POST | /scim/v2/Users | Create a User. |
| GET | /scim/v2/Users/{userID} | Get a User. |
| PUT | /scim/v2/Users/{userID} | Update a User. |
| GET | /user-roles | Retrieve user roles. |
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 identity-administration side of U.S. Bank's freight platform, spoken in standard SCIM 2.0 — the protocol enterprise IdPs use to push user accounts into SaaS systems. The user store behaves like one: POST /scim/v2/Users echoes your attributes under a server-minted UUID, GET returns the stored user intact, and PUT folds changed fields into the record, deactivation flag included. The discovery trio provisioning engines interrogate first is fully modeled — a ServiceProviderConfig declaring every optional SCIM feature off, resource types naming a required FreightUser schema extension, and the attribute-level User schema with mutability and uniqueness metadata per field. Around the standard sit the platform fixtures: the Converse Corp organization hierarchy, a Billing role, and an approval policy capped at a curious 999.999.
Create first, always. A user minted through POST supports the full read-and-update cycle, but aiming PUT at an id that was never created doesn't return the tidy SCIM 404 the read route gives — the update fails server-side and can leave a corrupt entry that breaks the roster listing for everyone until the shared store resets. It's a sharp edge worth knowing about, and a reason to keep provisioning tests on ids the sandbox issued to you.
No — and the sandbox tells you so the standard way. The ServiceProviderConfig declares filter unsupported along with patch, bulk, sorting, and etags, so a well-behaved provisioning engine reads that manifest and never sends the operators. If your integration consults ServiceProviderConfig before choosing its feature set, this template rewards it; if it assumes filtering everywhere, this is a cheap place to find out.
A required extension urn the resource-type route attaches to User — the platform's freight-specific attributes ride in it, the way enterprise SCIM deployments bolt domain fields onto the core schema. Provisioning code that hard-codes the core User urn alone will build payloads the real platform rejects, so the discovery response doubles as a conformance nudge.
They're the operators. Accounts provisioned here — scoped by the organization roster and the Billing-style roles — are the people who submit invoices, work audit exceptions, and pull reports in the Freight Payment Transactions template. Provision through one sandbox, transact through the other, and the pair covers the platform's admin and money sides.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.