API template library

Plaid Issues mock API and live sandbox

A WireMock simulation of Plaid's REST API — covering institution-incident search, issue detail, and update subscriptions.

Vendor
Plaid
Functionality
Issue lookup and subscriptions
Spec version
2020-09-14_1.688.6
Endpoints
3
Stubs
3
Protocol
REST
Validation
AI-validated Before publication, an AI agent exercised these endpoints against the real Plaid API through WireMock's recording proxy, and the recorded traffic was used to verify each stub's request and response shapes.

Live sandbox · no signup, no API key

Plaid Issues

A running WireMock Cloud instance of this template, callable right now from a terminal, a script, or an AI agent.

Base URL
https://eml74.wiremockapi.cloud

POST Static - /issues/search

curl -s -X POST 'https://eml74.wiremockapi.cloud/issues/search' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Static - /issues/get

curl -s -X POST 'https://eml74.wiremockapi.cloud/issues/get' \
  -H 'Content-Type: application/json' \
  -d '{}'

POST Static - /issues/subscribe

curl -s -X POST 'https://eml74.wiremockapi.cloud/issues/subscribe' \
  -H 'Content-Type: application/json' \
  -d '{}'
Method Path Summary
POST /issues/get Get an Issue
POST /issues/search Search for an Issue
POST /issues/subscribe Subscribe to an Issue

Unauthenticated WireMock Cloud demo sandbox for Plaid — not an official Plaid sandbox, and it returns simulated example data only.

What's inside the Issues template

Issues is Plaid's incident-visibility surface — the API answer to "is this bank having a problem right now" — and the template stocks it with two contrasting incidents. Issue 000001 is a Link-session failure in FIX_IN_PROGRESS that spans two institutions at once; issue 000002 is a rate-limit-driven sync error at a third bank, sitting in AWAITING_RESOLUTION. Each record carries parallel institution_names and institution_ids arrays, a one-line summary, a longer detailed_description, and a created_at timestamp — the complete shape a status banner, an ops dashboard, or a support macro consumes.

  • Search — the two-incident result set with statuses at different lifecycle stages
  • Detail — the single-issue read serving the multi-institution Link failure
  • Subscriptions — the subscribe route's acknowledgement for webhook-based updates

Frequently asked questions

No — the detail route serves issue 000001 whatever issue_id the request names. Both fixtures are reachable, just asymmetrically: search returns the pair, detail returns the first. Point status-specific assertions at the search results and treat the get route as a fixed single-record read.

The acknowledgement is the whole exchange. In production, status changes reach subscribers as webhook deliveries, and no unsolicited traffic ever leaves this instance — so pair the subscribe call here with synthetic webhook payloads posted at your own endpoint when testing the update-handling half.

Because one incident can affect several banks — the fixture's Link failure names two institutions in a single record. UI that renders an affected-institutions list, or dedup logic that folds an incident into per-bank status rows, needs the plural handling this shape forces.

Different granularity. The item_logins block on the Institutions template reports a bank's rolling connection-success health; an Issue is a discrete, tracked incident with a lifecycle and an eventual resolution. Status pages typically want both: the gauge and the incident feed.

Vendor names identify APIs represented by WireMock template sources. This page does not imply vendor endorsement, certification, partnership, or official integration status.