MX Platform API vs Plaid

MX Platform API

Three public OpenAPI files, llms.txt, Markdown docs and a written version policy with 18 months of support and Deprecation and Sunset response headers. No price, client agreement or SLA is published, production keys need MX's approval, every calling IP address must be allowlisted, and the status page records three platform-wide error incidents since 10 July 2026.

Plaid

Public OpenAPI file, llms.txt with about 250 entries and a Markdown twin of every docs page. No prices before a Production application, and Transactions, Liabilities and Investments bill per Item each month until removed.

MX Platform API

1. Send Accept: application/json, Accept-Version: v20260929 and Basic auth of client_id:api_key on every call. A missing version returns 406
2. Ask the owner to allowlist the calling machine's static IP in the Client Dashboard first. Other addresses get 403, and some failed authentication returns 404
3. Test against https://int-api.mx.com with institution mxbank, username mxuser and any password. It has no aggregation throttle
4. Set your own id when creating users and members. A repeat returns 409, which makes a retried create safe
5. Expect 202 without an error when a standard aggregation is throttled (three hours by default). Balance checks stop at 5 per member every 2 hours with 429
6. Pass includes[]=merchant or includes[]=category as an array on transaction lists. A comma-separated string returns 400

Plaid

1. Point calls at https://sandbox.plaid.com until you hold a Production secret; request shapes are the same
2. Create a sandbox Item with /sandbox/public_token/create and ins_109508, then /item/public_token/exchange, no Link UI needed
3. Use /transactions/sync with its cursor and back off on 429 RATE_LIMIT_EXCEEDED yourself, since no Retry-After comes back
4. Call /item/remove when the user is done, or subscription products keep billing
5. Send an idempotency_key on /transfer/authorization/create so a retried request can't authorise twice