A WireMock simulation of Plaid's REST API — covering the applications connected to an Item and the scope updates and unlinks that govern them.
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 Static - /application/get
curl -s -X POST 'https://6g8k1.wiremockapi.cloud/application/get' \
-H 'Content-Type: application/json' \
-d '{}'POST Static - /item/application/list
curl -s -X POST 'https://6g8k1.wiremockapi.cloud/item/application/list' \
-H 'Content-Type: application/json' \
-d '{}'POST Static - /item/application/scopes/update
curl -s -X POST 'https://6g8k1.wiremockapi.cloud/item/application/scopes/update' \
-H 'Content-Type: application/json' \
-d '{}'Spec catalog — The Plaid API (2020-09-14_1.688.6) · 5 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /application/get | Retrieve information about a Plaid application |
| POST | /item/activity/list | List a historical log of user consent events |
| POST | /item/application/list | List a user’s connected applications |
| POST | /item/application/scopes/update | Update the scopes of access for a particular application |
| POST | /item/application/unlink | Unlink a user’s connected application |
Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.
Five endpoints back the "manage your connections" screen — the place a user reviews which apps reach their bank data and cuts off the ones they no longer want. /application/get serves the disclosure profile such screens render: Example App's display name, logo URL, legal name and San Francisco address, a reason_for_access sentence, and a stated use case. /item/application/list attaches one connected application to the Item, /item/activity/list answers with a deliberately empty history, and the two write routes — scope updates and unlink — acknowledge with a request_id, completing the request/response contract of every control the screen exposes.
Empty activities and last_data_access_times arrays are the fixture — the zero state most connection-management UIs only meet in production, when a fresh Item has no history yet. Empty-list rendering gets covered free here; for a populated version of the same event vocabulary, the Consent template serves a five-event grant-and-revocation log.
No — both acknowledge and change nothing, so the application list reads the same before and after an unlink. The contract being exercised is the request shape and the ack; a roster that actually shrinks when an app is unlinked is scenario work for a WireMock Cloud copy.
They're the trust surface. reason_for_access and use_case are the sentences a consent screen shows a wary user, and the company identity block — legal name, city, region, country — is what distinguishes a legitimate requester from an impostor. The fixture populates every one of them, so a disclosure card renders complete rather than gap-toothed.
In production these routes take an access token; here every request succeeds bare, since nothing in the matching inspects credentials. That makes exploration painless and makes one habit important: use invented identifiers in anything you send, because the instance is shared and unauthenticated by design.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.