A WireMock simulation of Chase JPMorgan's REST API — covering user record lookup, roster search, and application-level activate and deactivate actions.
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
GET Get User by ID
curl -s -X GET 'https://y0wmv.wiremockapi.cloud/users/41526alice'POST Search Users
curl -s -X POST 'https://y0wmv.wiremockapi.cloud/users/search' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — User Status Management API (2.0.5) · 3 endpoints
| Method | Path | Summary |
|---|---|---|
| GET | /users/{id} | Get User by userId |
| POST | /users/actions | Modify User Status |
| POST | /users/search | Search Users |
Unauthenticated WireMock Cloud demo sandbox for Chase JPMorgan — not an official Chase JPMorgan sandbox, and it returns simulated example data only.
Version 2.0.5 of J.P. Morgan's digital-channel user administration surface, in three moves. The lookup route resolves one canonical record — Alice Bob, user id 41526alice, login Alice123, holding an ACTIVE entitlement to the ACCESS application — while any other id draws a structured Not Found whose context array names the offending id field. The search route answers with the roster that matters for status-handling code: three users, one in each state a client has to render — Alice ACTIVE, Rose INACTIVE, and Jack mid-transition at ACTIVATION_IN_PROCESS. The actions route routes on the verb in your body: an ACTIVATE lands on one stub and comes back ACTIVATION_IN_PROCESS, a DEACTIVATE on its sibling at INACTIVATION_IN_PROCESS, each response carrying a user id minted for that call and a statusUpdatedAt stamped at the moment of the request — the in-flight acknowledgment shape of an operation the real platform completes asynchronously.
The action stubs acknowledge, they don't consult. Whatever userId or applications block you post, the response is a generic User Profile record under a fresh UUID with empty applicationId and loginId fields — none of your input is read back, and re-fetching Alice afterward shows her still ACTIVE. What the route does verify is the contract: your request reached the right stub for its action value, and your client parsed the transition-state body. Assert on the status string and the timestamp, not on identity fields.
Exactly two. ACTIVATE and DEACTIVATE each have a dedicated stub, selected by the action value in your body; anything else — an UNLOCK, a missing action field, an empty object — falls through to WireMock's not-matched diagnostic rather than an API error. That fall-through is worth recognizing on sight, because it means no stub exists for the request, which is a different situation from the designed Not Found the lookup route returns for unknown user ids.
The search accepts any criteria body and returns the same three users, so filtering logic can't be exercised here — what can be is state rendering, since the trio spans ACTIVE, INACTIVE, and ACTIVATION_IN_PROCESS in one response. Note that the roster and the lookup route are separate layers: the three search UUIDs all answer Not Found when fetched by id, and 41526alice never appears in search results. Tests should treat the roster as display data and Alice as the read model.
This surface governs whether a user may sign in to a channel application — status is the payload, and the record is thin. The Consumer Profile Management template owns the customer data itself — addresses, payment methods, 3-D Secure state — and runs a genuinely stateful CRUD store where writes persist. Entitlement flows rehearse here; profile-data flows, and any test that needs its writes to stick, belong there.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.