Plaidly Docs

Error Model

How Plaidly reports errors today, and the envelope the platform is converging on

Error Model

Live today

Every non-2xx response body is:

{
  "code": 5,
  "message": "idempotency key was already used with a different payload"
}
FieldTypePresent
codeinteger (int64)always
messagestringalways

code is a small integer enum, not a machine-readable string slug:

codeMeaning
1Internal error
2Not found
3Bad request
4Too many requests (rate limited)
5Conflict (e.g. idempotency key reused with a different payload)
6Client cancelled the request
7Forbidden / auth failure
8Service unavailable

There is no field, remediation, request_id, or retryable in the response body today. Correlate a failed request using the response headers and your own request timestamp/URL when filing a support request.

Planned envelope

The phase-1 agent-first design locks in a richer, additive envelope:

{
  "code": "conflict",
  "message": "idempotency key was already used with a different payload",
  "field": "amount",
  "remediation": "retry with a new Idempotency-Key or the original payload",
  "request_id": "req_01HX9K...",
  "retryable": false
}
FieldTypeRequiredNotes
codestringyesStable machine-readable slug (e.g. conflict, not_found) — replaces the current integer code
messagestringyesHuman-readable description
fieldstringnoPresent when the error is attributable to a single request field
remediationstringnoA short hint on how to resolve the error
request_idstringnoCorrelates the error to server-side logs
retryablebooleannoWhether retrying the exact same request is expected to succeed

message and code remain the only fields you can depend on being present; everything else is additive. Agents and SDKs should treat unknown fields as ignorable rather than failing to parse.

Until this ships, do not write client code that assumes code is a string or that field/remediation/request_id/retryable exist — check for their presence defensively if you want to be ready early.

On this page