MX Technologies has 31 API pages on apis.io. The one to read is the MX Technologies Members API. In MX’s model a user is a person, and a member is that person’s connection to one financial institution. Every account, transaction, statement and balance downstream hangs off a member. Accounts, Transactions and Insights are views of the data. Members is the machinery that gets it.
What the operations do
The page lists 26 operations. They are 13 distinct operations, each published twice. Here are the 13:
| Stage | Operations |
|---|---|
| Lifecycle | list, create, read, update, delete member |
| Connect | list member credentials, list member challenges, resume aggregation, read member status |
| Pull data | aggregate member, check balances, identify member, verify member |
This is the part of open banking that happens away from the happy path. A connection is created with credentials. The institution comes back with an MFA challenge. The integrator lists the challenges and answers them through resume. Then it polls status until the connection settles, and the spec warns that the old status field is headed for deprecation in favor of connection_status. Aggregate, check balances, identify and verify each start a separate process against the institution. Aggregate, check balances and identify return 202 Accepted because the work happens later.
Why every operation appears twice
MX publishes two definitions of the MX Platform API. The contract behind this page merges the tagged operations from both. The undated one spells the paths /users/{user_guid}/members/{member_guid}. The one dated v20250224 spells them /users/{user_identifier}/members/{member_identifier}. Both also carry member-scoped paths the Members page does not list, among them extend_history and oauth_window_uri.
So the 26 rows are one API across a parameter rename, and the page’s own summary line says 20, which matches neither. Some of that is our bookkeeping. The rest is MX’s. The dated definition still uses the old guid spelling for statements, rewards and the verifiable-credentials paths under the same member, so a client written against the new version has to know which convention each path follows.
How it reads for an agent
MX scores 70.7, exemplar, carried by operational transparency at 88.9 and access clarity at 87.4. All 26 contracts are MX’s own, none derived, and all are callable. Agent Readiness is 29.1, agent-ready, and the unlit dimensions line up with this API’s weak spots. Idempotency is unlit, and create member and aggregate member are both POSTs that start work at a bank. Reversibility is unlit too. For an agent, “retry after a timeout” on an aggregation it cannot identify as a duplicate is the risky call on this surface.
Takeaway
Members is the best-designed piece of MX’s surface, and it models the MFA loop honestly instead of hiding it behind a widget. What would help it most is a single canonical path convention across the dated definition, and a documented idempotency key on the POSTs that reach an institution.
The reference is at docs.mx.com. The catalog view is at apis.io/apis/mx-technologies/mx-technologies-members-api/.