LEGACY GUIDEThis guide is for Platform API v2011101. For guidance on the newest version, see Connectivity Integration Guides.
- Create a user.
- Search for an institution.
- Get the credentials required by the institution.
- Create an OAuth or non-OAuth member, which connects the user to the institution.
- Load the OAuth URI (if you created an OAuth member).
- Start aggregating data.
- Poll the member’s connection status.
- Answer multifactor authentication, if necessary.
- Poll the member’s connection status again until it reaches an end state. A successful end state is when the
connection_statusisCONNECTEDand theis_aggregatingfield changes fromtruetofalse. - List the member’s owner information or read a particular owner’s information.
1. Create a User
A user represents your end user in the MX Platform. Make a request to the Create User endpoint (POST /users).
We recommend that you include a unique id of your choice with the request. You may also include metadata, such as the date the user was created or the end user’s name. Don’t include any sensitive information here, such as credentials.
INFONone of these parameters are required, but the
user object can’t be empty. We recommend that you always set the id parameter when creating a user.user an MX-defined guid (or user_guid when appearing outside the user object). Between your id and the guid, you can map between your system and ours. You’ll need the user guid for nearly every request on the MX API, at least when using basic authorization.
- Request
- Response
2. Search for an Institution
To create a member, you need to know what financial institution the member should be connected to and what type of credentials the institution expects to get. First, search for an institution using query parameters on the List Institutions endpoint (GET /institutions?name={string}&supports_account_identification=true).
INFOThe example searches for our test institution MX Bank (see Testing for more information). It also limits results to institutions that support AOI.
name query parameter. Make a note of the code you find in the example response; you’ll need this for the next step.
- Request
- Response
3. Get the Institution’s Required Credentials
INFOIf you plan on creating an OAuth member, you can skip this step since the user will instead log in directly through the financial institution’s site.
GET /institutions/{institution_code}/credentials). Include the institution code retrieved from the previous step in the request path.
This endpoint returns the GUID for each required credential, which is used to match the credentials the end user provides to the required credential type when creating a member.
- Request
- Response
4. Create a Member
You can create an OAuth or non-OAuth member. Before you can use OAuth, you must register with the financial institution, unless you’re using one of our test institutions. See Registration for more info.Create a non-OAuth member
Create a non-OAuth member
For this step, you need to have already gathered the values needed for each credential from the end user. The following example uses the MX Bank institution and requires a username and a password; it sets the username to
mxuser and the password to password, which are the MX Bank credentials for the test user.Make a request to the Create Member endpoint (POST /users/{user_guid}/members). The response includes the newly created member.In your request:- Required Put the
user_guidin the path. - Required Include the credential GUIDs and their values in the
credentialsarray. - Recommended Set
idto a unique value when creating a member so you can sync between your systems and ours. - Recommended Set
metadata. - Optional If you don’t want account and transaction data, disable its aggregation, which is automatically started when a member is created. To do this, set
"skip_aggregation": true.
Request
Response
Create an OAuth member
Create an OAuth member
Make a request to the Create Member endpoint (
POST /users/{user_guid}/members). The response includes the newly created member.In your request:- Required Put the
user_guidin the path. - Required Set
"is_oauth": true. - Required Set
client_redirect_urlso we can send you UI messages with the right scheme. This can be any string, but we’ll usehttps://mx.comin this guide. - Required Set
institution_code, which you got from step 2. - Recommended Set
idto a unique value when creating a member so you can sync between your systems and ours. - Recommended Set
metadata. - In a mobile implementation only Set
"referral_source": "APP". This tells MX to use theclient_redirect_urlyou provided so you can get back to your app. - Optional If you don’t want account and transaction data, disable its aggregation, which is automatically started when a member is created. To do this, set
"skip_aggregation": true.
oauth_window_uri.- Request
- Response
5. Load the OAuth URI (if you created an OAuth member)
INFOIf you created a non-OAuth member, you can skip this step.
oauth_window_uri field in the last step returned a link that the end user will open to log into their financial institution and successfully connect their data to our API.
If you’re following this guide for testing purposes, you must enter the credentials mentioned in one of the MXCU testing guides. MXCU is our recommended institution for testing OAuth flows.
6. Start Aggregating Data
Now we can actually begin the process of gathering AOI data. Make a request to the Identify Member endpoint (POST /users/{user_guid}/members/{member_guid}/identify). This request only starts the process of aggregating AOI data (actually reading the aggregated data comes later). The response will be a member object with information about the state of the AOI aggregation that just started.
- Request
- Response
7. Check the Connection Status
Check the connection status of the member to get information on the state of the connection. Important fields includeconnection_status, is_being_aggregated, and successfully_aggregated_at. The is_being_aggregated field will tell you whether the process is ongoing or complete. When you see connection_status: CONNECTED and is_being_aggregated: false at the same time, the process is done and you can move on to the next step. The successfully_aggregated_at field will give the exact time the process completed successfully, but of course will not update if the process fails.
You may need to check the connection status several times until an end state is reached.
Make a GET request to the /users/{user_guid}/members/{member_guid}/status endpoint. The response in the example shows a successful end state.
- Request
- Response
8. Deal with Multifactor Authentication
Aggregating data may trigger multifactor authentication (MFA) from the institution associated with the member. This is indicated by"connection_status": "CHALLENGED".
See the section on answering MFA challenges for more information.
For this guide, we’ll assume there was no MFA and move on to the next step.
9. List Account Owners
The aggregation was successful and you can now list all account owners associated with the member. Make a request to the List Account Owners by Member endpoint (GET /users/{user_guid}/members/{member_guid}/account_owners).
- Request
- Response
SUCCESSYou’ve successfully returned Account Owner Identification data!

