MX Platform API vs Yapily

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.

Yapily

llms.txt, llms-full.txt, a no-auth docs MCP server and an OpenAPI file. No public pricing; live access starts with a sales form.

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

Yapily

1. Read llms-full.txt once and cache it; it's the whole documentation in one fetch
2. Add the Modelo sandbox in the Console before your first account-auth-request, or institutions comes back empty
3. Treat a 403 on a data call as a revoked or expired consent and send the user back through authorisation
4. Check the error source field first; USER and INSTITUTION failures won't clear on retry
5. In the UK, call extend-consent with lastConfirmedAt before the reconfirmBy date, or the consent lapses at 90 days