Obtain API keys (client_id and api_key) from the MX developer portal and authenticate all requests using HTTP Basic auth with client_id as the username and api_key as the password.
Create a user for each end user in your system by POSTing to /users with an optional external identifier; receive the user's guid.
Generate a widget URL for the MX Connect widget by POSTing to /users/{user_guid}/widget_urls with widget_type=connect_widget; embed this URL in an iframe or webview in your application.
Handle the postMessage or callback from the Connect widget on successful account linking to receive the member_guid of the newly connected institution member.
Retrieve accounts by calling GET /users/{user_guid}/members/{member_guid}/accounts; each account has a guid used for subsequent data calls.
Fetch transactions by calling GET /users/{user_guid}/transactions with optional date range filters (from_date, to_date) and pagination parameters (page, records_per_page).
Known gotchas
MX performs data aggregation asynchronously after a member is connected; immediately after the Connect widget callback, the member status may still be CONNECTING or VERIFYING — poll GET /users/{user_guid}/members/{member_guid} until status is CONNECTED before fetching accounts and transactions.
MX auto-refreshes member connections periodically, but connections can enter a DEGRADED or IMPAIRED state when the institution changes its login flow; build a reconnection prompt that relaunches the Connect widget in update_credentials mode for the affected member.
Transaction data from MX is enriched with merchant names, categories, and geolocation; the raw description from the institution is preserved in the original_description field — use the enriched fields for display but store the original for reconciliation.
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp