A WireMock simulation of Plaid's REST API — covering the FDX recipient directory, single-recipient lookups, and the notification receiver.
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 Static - GET /fdx/recipients
curl -s -X GET 'https://2282l.wiremockapi.cloud/fdx/recipients'POST Static - POST /fdx/notifications
curl -s -X POST 'https://2282l.wiremockapi.cloud/fdx/notifications' \
-H 'Content-Type: application/json' \
-d '{}'GET Static - GET /fdx/recipient/{recipientId}
curl -s -X GET 'https://2282l.wiremockapi.cloud/fdx/recipient/your-recipientId'Spec catalog — The Plaid API (2020-09-14_1.688.6) · 3 endpoints
| Method | Path | Summary |
|---|---|---|
| POST | /fdx/notifications | Webhook receiver for fdx notifications |
| GET | /fdx/recipient/{recipientId} | Get Recipient |
| GET | /fdx/recipients | Get Recipients |
Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.
This is the data-provider corner of the Plaid API — the /fdx/ namespace a financial institution works with when Plaid brokers its FDX-standard data sharing — and it behaves accordingly: the two read routes are genuine GETs, unusual in an API family that POSTs nearly everything. /fdx/recipients answers with a roster of two data recipients, each carrying a client name, legal name, logo URI, category, joined date, and a connection count, so a provider dashboard listing "who receives our customers' data" has realistic variety — a robo-advisor with 128 connections beside an eCommerce client with 209. The single-recipient route serves a trimmed four-field record, and /fdx/notifications stands ready as the webhook intake.
Any id in the path — including one copied from the roster — returns the same fixed record, whose own recipient_id matches neither roster entry. Wire assertions to the record's field structure rather than to id round-tripping, and reserve per-id lookups for a WireMock Cloud copy with one stub per recipient.
A bare 200 with an empty body — it's a receiver, not a publisher. That inverts the usual mock relationship: instead of your code calling Plaid, this route plays the party being notified, so the delivery side of your FDX event pipeline — serialization, retries, status handling on the ack — can run against it directly.
The fixture ships that way — Another Example Client's joined_date sits in the future — and it makes a serviceable test case for date handling: sorting by join date, "member since" rendering, and any sanity check that flags impossible dates all get exercised by data the schema itself declares valid.
Same relationship, opposite vantage point. Here a provider surveys the recipients receiving its data; the Permissions Manager template models the consumer's view — which applications an individual Item is connected to, and the controls for narrowing or severing them.
Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.