What's in this guide

In this guide, you’ll find lots of information to help you get up and running with Atrium. It includes material on about how the API works, common terminology, common problem scenarios, a Postman collection and downloadable examples in multiple languages, steps on how to test certain Atrium features, broad workflows for common tasks, and more.

This is not designed to be comprehensive but to provide a broad overview of common tasks and issues. Refer to our detailed API reference for more specific information about Atrium resources, endpoints, and configuration options.

Whitelisting

Before you can work within Atrium’s production environment, your IP addresses must be whitelisted. If you haven’t been whitelisted, you’ll see 403 Forbidden errors. You can whitelist IP addresses on your account profile.

Atrium’s vestibule environment does not require any whitelisting.

Resource structure

Atrium is structured around five major resources, each with its own attributes and endpoints:

Resource	Description
`institution`	An `institution` represents a financial institution (FI) like Chase or Wells Fargo. It’s important to point out that many real-world FI will actually have several different `institution` objects within Atrium. This is because, for example, the mortgage division of Wells Fargo might use a separate system than its everyday banking division, which is different from its credit card division, etc.
`user`	A `user` represents a person using Atrium via your application, be it a mobile app, web app, desktop app, etc.
`member`	A `member` represents the relationship between a `user` and an `institution`. A `user` may have one `member` each for their bank, their mortgage broker, their credit card provider, etc. Aggregation takes place via members.
`account`	An `account` represents a financial account held by an FI, e.g., a user’s checking or savings account. A member may have more than one account associated with it. For instance, a user may have both a checking and savings account associated with one Chase login and therefore would have two accounts associated with one `member`.
`transaction`	A `transaction` represents any instance in which money moves into or out of an `account`, such as a purchase at a business, a payroll deposit, a transfer from one account to another, an ATM withdrawal, etc. Each `transaction` belongs to only one `account`.

Creating users

To create a new user, call the create user endpoint. It’s a good idea to send along a unique identifier with your request to create a new user. Atrium will also give each new user a unique GUID in the guid field within the user object. The Atrium user GUID also appears in the user_guid field when not inside the user object. The identifier and guid allow you to easily map between your system and Atrium.

You may also include metadata, such as the date the user was created, if desired. You can read more on identifiers and metadata on our API reference page.

An example request for creating a user is shown below.

Example request

1
2
3
4
5
6
7
8
9
10
11
$ curl -i -X POST 'https://vestibule.mx.com/users' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'Content-Type: application/json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}' \
  -d '{
        "user": {
          "identifier": "unique_id",
          "metadata": "{\"first_name\": \"Steven\"}"
        }
      }'

Example response

1
2
3
4
5
6
7
8
{
  "user": {
    "guid": "USR-fa7537f3-48aa-a683-a02a-b18940482f54",
    "identifier": "unique_id",
    "is_disabled": false,
    "metadata": "{\"first_name\": \"Steven\"}"
  }
}

Creating members

Once a user is created, we recommend creating a member with our MX Connect widget. MX Connect allows end users to easily choose an institution to connect to, enter credentials, update credentials, and answer multi-factor authentication.

If your system or application is unable to support MX Connect, you can always call the endpoint directly in your code. To create a member via endpoints, you’ll follow the workflow below:

Once your member has been created, you’ll want to call the read member status endpoint to determine whether answering MFA is required or to update credentials as needed.

The steps outlined below assume you’re creating a new member on an existing user.

1. Search for an institution

Endpoint:

GET /institutions/{institution_code}

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/institutions/chase' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "institution": {
    "code": "chase",
    "medium_logo_url": "https://content.moneydesktop.com/storage/MD_Assets/Ipad%20Logos/100x100/default_100x100.png",
    "name": "Chase Bank",
    "small_logo_url": "https://content.moneydesktop.com/storage/MD_Assets/Ipad%20Logos/50x50/default_50x50.png",
    "supports_account_identification": true,
    "supports_account_statement": true,
    "supports_account_verification": true,
    "supports_transaction_history": true,
    "url": "https://www.chase.com"
  }
}

2. Get institution required credentials

Endpoint:

GET /institutions/{institution_code}/credentials

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/institutions/chase/credentials' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
{
    "credentials": [
        {
            "field_name": "login_email",
            "guid": "CRD-12ce94ad-032b-5441-8cb3-d7ebe3a35676",
            "label": "Email Address",
            "display_order": 0,
            "type": "LOGIN"
        },
        {
            "field_name": "login_password",
            "guid": "CRD-305767e4-f464-765b-8f83-881b5bd307ec",
            "label": "PayPal password",
            "display_order": 1,
            "type": "PASSWORD"
        }
    ]
}

3. Create a member

Endpoint:

POST /users/{user_guid}/members

Example request

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
$ curl -i -X POST 'https://vestibule.mx.com/users/{user_guid}/members' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'Content-Type: application/json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}' \
  -d '{
        "member": {
          "institution_code": "chase",
          "credentials": [
            {
              "guid": "CRD-1ec152cd-e628-e81a-e852-d1e7104624da",
              "value": "ExampleUsername"
            },
            {
              "guid": "CRD-1ec152cd-e628-e81a-e852-d1e7104624da",
              "value": "Pa$$vv@Rd"
            }
          ],
          "skip_aggregation": true
        }
      }'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "member": {
    "aggregated_at": "2016-10-13T17:57:36+00:00",
    "connection_status": "CONNECTED",
    "guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
    "identifier": "unique_id",
    "institution_code": "chase",
    "is_being_aggregated": true,
    "metadata": "{\"credentials_last_refreshed_at\": \"2015-10-15\"}",
    "name": "Chase Bank",
    "status": "INITIATED",
    "successfully_aggregated_at": null,
    "user_guid": "USR-fa7537f3-48aa-a683-a02a-b18940482f54"
  }
}

4. Poll the member status

Endpoint:

GET /users/{user_guid}/members/{member_guid}/status

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/status' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "member": {
    "aggregated_at": "2019-06-08T17:21:05Z",
    "connection_status": "CONNECTED",
    "guid": "MBR-a4652b66-3ee5-cb9f-295a-72eddef61db5",
    "has_processed_accounts": true,
    "has_processed_transactions": true,
    "is_authenticated": true,
    "is_being_aggregated": false,
    "status": "COMPLETED",
    "successfully_aggregated_at": "2019-06-07T21:16:03Z"
  }
}

Aggregating data and dealing with MFA

Aggregating data about accounts and transactions belonging to a member is a multi-step process. This same general outline applies to all aggregation-type features, with the necessary endpoint substitutions, of course: account verification, identity verification, extended transaction histories, fetching statements, account balance aggregation, and standard aggregation.

In general, it involves:

Making a request to the aggregate member endpoint (or an analogous endpoint);
Polling the member for changes in the state of the aggregation using the read member connection status endpoint and looking at fields such as connection_status, is_being_aggregated, is_authenticated, has_processed_accounts, etc.;

Using the Connect widget provided by MX greatly simplifies and automates steps 2 and 3;

If necessary, answering MFA challenges using the resume aggregation endpoint.
Reading aggregated data using the list accounts and list transactions endpoints (or analogous endpoints).

Atrium automatically aggregates each member every 24 hours. This process is called background aggregation. It ensures that end users’ data will always be up to date. If an end user is present, you may also manually run a foreground aggregation using the general steps specified above. End users must be present during foreground aggregations because they may run into MFA, credential update requests, terms and conditions agreements, or any number of other situations requiring end-user input.

Both foreground and background aggregation may be manually prevented by disabling a user. A user must be re-enabled before any aggregation can be attempted.

Atrium may also suspend background aggregation on a particular member in some circumstances, such as when several consecutive aggregation attempts fail. However, you may always attempt a foreground aggregation on a suspended member.

Running multiple aggregation-type events on a member

Your particular application may use several of Atrium’s aggregation-type processes, including standard aggregation and premium features like fetching statements, verifying identity, etc. All of these processes are run on a specific member, but they cannot be run simultaneously — each process must reach an end state before a new process can be started.

Furthermore, when running multiple processes in succession, standard aggregation should always be performed first in the series. This is because any aggregation-type process will prevent a new standard aggregation for the next three hours; however, running a standard aggregation has no effect on the timing of premium features.

If a member already has a process running and you attempt to run an aggregation-type process on it, you may get one of two status codes:

If an event of the same type is already running, you’ll get a a 202 Accepted status;

For example, you called verify member when a verification is already running;
You can tell that a process is already running because the is_being_aggregated field will be true.

If an event of a different type is running, you’ll get a 409 Conflict status;

For example, you called identify member when a standard aggregation is already running.

MFA and connection statuses

Some institutions require multiple steps for authentication; this process is called multi-factor authentication (MFA). Basically, it is a back and forth dialogue between the end user, the partner’s application, and the institution. After the initial credentials are provided, the institution can either grant access or present an MFA challenge.

When an MFA challenge is presented, the member’s connection_status will be CHALLENGED. You must get the correct answer to the challenge from the end user and send it to MX so aggregation can continue. More than one MFA cycle may occur. Financial institutions will typically have multiple MFA questions and may ask a new question in future aggregations. Partners must continue to answer the institution’s challenges until the institution grants access to the end user’s account.

A single aggregation may also enter multiple CHALLENGED states. A typical scenario for this is when a list of options is presented along with a question such as, “Where should we send an authentication token?”

MFA can occur at any time on any aggregation, so even if authentication has been successful in the past, the institution may require an end user to authenticate again. Furthermore, aggregation may trigger MFA even if end users can successfully log into their online banking portal without MFA using the same credentials.

Member connection statuses

The connection_status field appears on all member resources and indicates the current state of aggregation for that particular member. Partners can poll a particular member using the read member connection status endpoint to follow changes in the connection_status throughout an aggregation.

The connection_status should be used in conjunction with several other member fields to determine future actions, including aggregated_at, is_being_aggregated, and successfully_aggregated_at, has_processed_accounts and has_processed_transactions. Definitions for these fields appear at the end of this section. Definitions for all member fields are available here.

For example, when the connection_status is CONNECTED and the is_being_aggregated field is false, this means the latest aggregation attempt has finished and data for accounts and transactions should be pulled. Partners can use the field successfully_aggregated_at to determine when the last successful aggregation occurred.

When the status is CHALLENGED, an MFA challenge has been issued, requiring a separate workflow and end-user input.

The statuses CREATED, UPDATED, DELAYED, and RESUMED represent transient states for different points in the aggregation process and generally do not require a specific action or end-user input. They may, however, require continued polling until an end state is reached.

The statuses PREVENTED, DENIED, IMPEDED, IMPAIRED, REJECTED, EXPIRED, LOCKED, IMPORTED, DISABLED, DISCONTINUED, and CLOSED, represent end states that will require a new aggregation, and possibly end-user input for future success.

Member fields to poll during aggregation

Field Name	Data Type	Description
`aggregated_at`	String	The date and time the `member` the last aggregation was initiated, represented in ISO 8601 format with timestamp (e.g., 2015-04-13T12:01:23-06:00).
`connection_status`	String	This field indicates the state of a member’s aggregation, provided as a string. See member connection statuses for more information on possible values.
`is_being_aggregated`	Boolean	This field will be true if the member is being aggregated at the time of the request. Otherwise, this field will be false.
`successfully_aggregated_at`	String	The date and time the account was last successfully aggregated, represented in ISO 8601 format with timestamp (e.g., 2015-04-13T12:01:23-06:00).

Dealing with a CHALLENGED status

When a member comes back with a status of CHALLENGED, the aggregation will require answers to MFA from the end user. The challenges that must be answered are returned in the read member connection status response, nested inside the challenges array, as shown to the right. Simply polling this endpoint for changes in the connection_status should return challenges as quickly as possible.

Once MFA answers have been gathered for the challenged member, a request to the resume aggregation endpoint will send these answers and automatically resume the aggregation process. Aggregation will run until it either completes in an end state or enters into a state that requires action.

It is not uncommon for an aggregation to be CHALLENGED more than once.

Example response for read member connection status when the connection_ststus is CHALLENGED:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
{
  "member": {
    "aggregated_at":"2016-10-13T18:24:37+00:00",
    "challenges": [
      {
        "field_name": null,
        "guid": "CRD-1ec152cd-e628-e81a-e852-d1e7104624da",
        "label": "What city were you born in?",
        "type": "TEXT"
      }
    ],
    "connection_status": "CHALLENGED",
    "guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
    "has_processed_accounts": false,
    "has_processed_transactions": false,
    "is_being_aggregated": true,
    "status": "CHALLENGED",
    "successfully_aggregated_at": "2016-10-13T18:08:04+00:00"
  }
}

Dealing with multiple CHALLENGED states in one aggregation

A single aggregation may enter multiple CHALLENGED states. A typical scenario for this is when a list of options is presented along with a question such as, “Where should we send an authentication token?” As above, polling the read member connection status endpoint after resuming an aggregation should return these further challenges.

Here is a typical example: MFA is triggered and asks where to send an access token. The end user should be prompted for the answer and that answer provided to MX through the resume aggregation endpoint. The connection_status will move to a RESUMED state, but then will go back into a CHALLENGED state. This time, the end user should be prompted to enter the access token. If the second MFA challenge is answered successfully, the aggregation will typically proceed to an end state such as CONNECTED.

Dealing with a DENIED or PREVENTED status

If a member has a PREVENTED or a DENIED status, it means the authentication credentials are invalid; the end user must provide new credentials, and the member must be updated. A request to the list member credentials endpoint (as distinct from the separate list institution credentials endpoint) will return a list of the authentication credentials required for that member; corresponding input should be gathered from the end user, and that input should be passed to the update member endpoint.

Step-by-step guide for standard aggregation with MFA

The steps below show the ideal path for a standard aggregation on an existing member, including MFA. It’s the happy path, so to speak. There are other flows and situations, to be sure, but this gives you the basic outline of a common situation that requires resolution.

1. Check the member’s connection status

The first step is to check the member’s connection_status to determine whether aggregation is either necessary or possible. Each status indicates something different; some connection statuses mean that an aggregation will fail if attempted or that an aggregation is already in progress. See the sections above for more information, or consult the documentation on connection statuses for full details on exactly what each status means.

The following lists represent general guidelines.

In general, aggregation can be attempted for a member with the following connection statuses:

CREATED
CONNECTED
DEGRADED
DISCONNECTED
EXPIRED
FAILED
IMPEDED
RECONNECTED
UPDATED

In general, you must update credentials before aggregating a member with the following connection statuses:

PREVENTED
DENIED
IMPAIRED
IMPORTED

The following connection statuses represent a transitory state in an ongoing aggregation process:

CHALLENGED
DELAYED
REJECTED
RESUMED

You should not attempt aggregation on a member with the following connection statuses:

CLOSED
DISABLED
DISCONTINUED

Endpoint:

GET /members/{member_guid}/status

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/status' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "member": {
    "aggregated_at": "2019-06-08T17:21:05Z",
    "connection_status": "CONNECTED",
    "guid": "MBR-a4652b66-3ee5-cb9f-295a-72eddef61db5",
    "has_processed_accounts": true,
    "has_processed_transactions": true,
    "is_authenticated": true,
    "is_being_aggregated": false,
    "status": "COMPLETED",
    "successfully_aggregated_at": "2019-06-07T21:16:03Z"
  }
}

2. Aggregate the member

Making a POST request to the aggregate member endpoint initiates an aggregation.

Endpoint:

POST /members/{member_guid}/aggregate

Example request

1
2
3
4
5
$ curl -i -X POST 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/aggregate' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'Content-Type: application/json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "member": {
    "aggregated_at": "2016-10-13T18:07:57+00:00",
    "connection_status": "CONNECTED",
    "guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
    "identifier": "unique_id",
    "institution_code": "chase",
    "is_being_aggregated": true,
    "metadata": "{\"credentials_last_refreshed_at\": \"2015-10-15\"}",
    "name": "Chase Bank",
    "status": "INITIATED",
    "successfully_aggregated_at": "2016-10-13T17:57:38+00:00",
    "user_guid": "USR-fa7537f3-48aa-a683-a02a-b18940482f54"
  }
}

3. Check the connection status again

In this example, we see that the status has returned as CHALLENGED, meaning the aggregation has run into MFA. When CHALLENGED, the response to your status request will include a challenges object containing the MFA that the end user must answer.

Endpoint:

GET /members/{member_guid}/status

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/status' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "member": {
    "aggregated_at": "2019-06-08T17:21:05Z",
    "connection_status": "CONNECTED",
    "guid": "MBR-a4652b66-3ee5-cb9f-295a-72eddef61db5",
    "has_processed_accounts": true,
    "has_processed_transactions": true,
    "is_authenticated": true,
    "is_being_aggregated": false,
    "status": "COMPLETED",
    "successfully_aggregated_at": "2019-06-07T21:16:03Z"
  }
}

4. Answer MFA with the resume aggregation endpoint

Endpoint:

GET /members/{member_guid}/resume

Example request

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
$ curl -i -X PUT 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/resume' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'Content-Type: application/json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}' \
  -d '{
        "member":{
          "challenges":[
            {
               "guid": "institution-credential-guid",
               "value": "user-entered-value"
            },
            {
              "guid": "institution-credential-guid",
               "value": "user-entered-value"
            }
          ]
        }
      }'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
{
  "member": {
    "aggregated_at": "2016-09-30T14:31:45-06:00",
    "connection_status": "RESUMED",
    "guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
    "identifier":"unique_id",
    "institution_code": "chase",
    "is_being_aggregated": true,
    "metadata": "{\"credentials_last_refreshed_at\": \"2015-10-15\"}",
    "name": "Bank Name",
    "status": "RECEIVED",
    "successfully_aggregated_at": null,
    "user_guid": "USR-fa7537f3-48aa-a683-a02a-b18940482f54"
  }
}

5. Check the connection status again

Check the connection_status again, and keep checking until the aggregation reaches an end state, e.g., the is_being_aggregated field is false.

Endpoint:

GET /members/{member_guid}/status

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/status' \
  -H 'Accept: application/vnd.mx.atrium.v1+json' \
  -H 'MX-API-Key: {mx_api_key}' \
  -H 'MX-Client-ID: {mx_client_id}'

Example response

1
2
3
4
5
6
7
8
9
10
11
12
13
{
  "member": {
    "aggregated_at": "2019-06-08T17:21:05Z",
    "connection_status": "CONNECTED",
    "guid": "MBR-a4652b66-3ee5-cb9f-295a-72eddef61db5",
    "has_processed_accounts": true,
    "has_processed_transactions": true,
    "is_authenticated": true,
    "is_being_aggregated": false,
    "status": "COMPLETED",
    "successfully_aggregated_at": "2019-06-07T21:16:03Z"
  }
}

Steps for multiple-question MFA

Multiple-question MFA is very similar to single-question MFA explained above.

Aggregate the member (or create a new member)
Check the member connection status.
Answer the challenge using the resume aggregation endpoint
Check the connection status again.
Answer the next challenge.
Keep checking the connection status and answering challenges until an end state is reached.

Pulling data

When an aggregation is initiated, the member field aggregated_at will update. If it completes successfully, the successfully_aggregated_at field will be updated. These will help you determine when to pull the latest data after a foreground aggregation.

Transaction data can be accessed though three different endpoints: /users/{user_guid}/transactions, /users/{user_guid}/members/{member_guid}/transactions, and /users/{user_guid}/accounts/{account_guid}/transactions. The first will list all the transactions that belong to the user object. The second will return all transactions that belong to a member object. The third will return all transactions that belong to an ‘account’ object.

We recommend first listing available accounts, then listing transactions for a specific account.

Tools to get you running

The Postman collection below will allow you to start experimenting with Atrium immediately. The GitHub collections below demonstrate recommended workflows.

Postman

To easily get up and running, we recommend using Postman to experiment with Atrium. To do so you should:

Download Postman.
Install the Atrium Postman collection as explained here.
Add the following fields and your own values to a new Postman environment as explained here.

MX-API-Key
MX-Client-ID
Accept
Content-Type
baseURL
User
Member
Account

rapper libraries on GitHub

To see example workflows, please download one of our Atrium wrapper libraries in the language of your choice.

Testing your setup

MX provides a test institution in our development environment called MX Bank (institution code: mxbank) to test different aggregation responses. Creating a test member with this institution allows you to use custom credentials to mimic various aggregation workflows.

For example, you can use MX bank to test a complicated flow such as aggregation with MFA:

Aggregate the test member (or create a new test member)
Poll the member’s connection status.

With MX Bank, this will return with a challenges object.

Answer the challenge using the resume aggregation endpoint

On MX Bank, responding with "value": "challenge" will answer the first question correctly and trigger a follow-up challenge.

Poll the status again.

This will return another challenges object.

Answer the second challenge.

On MX Bank, answering with "value": "correct" will result in a successful aggregation.

Poll the status until an end state is reached.

MX also provides dozens of test endpoints to mimic the behavior of other Atrium features and workflows.

Test credentials for MX Bank

The test credentials for different situations are as follows:

Username	Password	Description
`test_atrium`	`password`	This mimics successful aggregation with no MFA.
`test_atrium`	`challenge`	This mimics a text-based MFA challenge. Answer with the word `correct` to successfully progress through MFA.
`test_atrium`	`options`	This mimics the “option list” type of MFA challenge. Select “correct” to successfully progress through MFA.
`test_atrium`	`image`	This mimics the image type of MFA challenge. Answer with the word “correct” to successfully progress through MFA.
`test_atrium`	`BAD_REQUEST`	This mimics not having a username and password on the `member`. The `member` status will go to `HALTED`.
`test_atrium`	`UNAUTHORIZED`	This mimics the `member` having invalid credentials. The `member` status will go to `DENIED`.
`test_atrium`	`INVALID`	This mimics the `member` having invalid `login` and/or `password` fields. The `member` status will go to `DENIED`.
`test_atrium`	`LOCKED`	This mimics a user being locked out of their banking institution. The `member` status will go to `DENIED`.
`test_atrium`	`SERVER_ERROR`	This mimics the financial institution having a server error. The `member` status will go to `HALTED`.
`test_atrium`	`UNAVAILABLE`	This mimics the financial institution having a “service unavailable” error. The `member` status will go to `HALTED`.

Testing with MXBank and OAuth

You will only be able to test OAuth flows in the integration environment with MX Bank (OAuth) (institution code: mx_bank_oauth).

When you select MX Bank (OAuth) from search, or load the Connect with it via current_institution_code. You should see the following screen before going to the OAuth provider:

Then you should end up on this page:

From here you can simply click “Authorize” to simulate authorizing and success paths, and “Deny” to simulate an error path.

Test endpoints

MX provides test endpoints to aid developers in working the flows and other issues with their Atrium integrations. Test endpoints return static data.

Certain endpoints can take a connection_status string as a URL parameter in place of the typical GUID. This will return a member in the state corresponding to the given connection_status.

Connection status definitions

Connection status id (integer)	Connection status (string)	Definition	Next steps	End-user message
null	null	The member exists but does not have credentials.	None.	None.
0	CREATED	The member is new and has not yet been aggregated.	Aggregate the member once the end user logs in; poll for a status update.	Connecting to {…} …
1	PREVENTED	MX is preventing aggregation until the member’s credentials have been updated.	Display end-user message; after end user has updated their credentials, aggregate again.	The last 3 attempts to connect have failed. Please re-enter your credentials to continue importing data.
2	DENIED	The credentials provided for the member were invalid.	Display end-user message; after end user has updated their credentials, aggregate again.	The credentials entered do not match your credentials at this institution. Please re-enter your credentials to continue importing data.
3	CHALLENGED	The member has been challenged by multi-factor authentication.	Display end-user message; follow MFA pathway; after the user answers MFA, poll for a status update.	To authenticate your connection to {…}, please answer the following challenge(s).
4	REJECTED	An MFA challenge was answered incorrectly.	Display end-user message; another challenge may follow or aggregation may need to be restarted.	The answer or answers provided were incorrect. Please try again.
5	LOCKED	The financial institution is preventing authentication. The end user must contact the financial institution.	Display end-user message.	Your account is locked. Please log in to the appropriate website for {…} and follow the steps to resolve the issue.
6	CONNECTED	The member was successfully authenticated and data is now aggregating.	Display the account as having been connected.	Connected to […] …
7	IMPEDED	The end user’s attention is required at their online banking institution, e.g., there is a marketing message that must be viewed, terms and conditions that must be accepted, etc.	Display end-user message.	Your attention is needed at this institution’s website. Please log in to the appropriate website for {…} and follow the steps to resolve the issue.
8	RECONNECTED	The member has been migrated to a new data source and aggregation is likely to trigger one-time password MFA. MX will not perform background aggregation in order to avoid unnecessarily disruptive texts, emails, etc. The member must be re-aggregated in the foreground with the end user present.	Aggregate the member once the end user logs in; poll for a status update.	Reconnecting to {…} …
9	DEGRADED	Aggregation has failed at least three times within a short period of time.	Display end-user message.	We are upgrading this connection. Please try again later.
10	DISCONNECTED	Aggregation has failed at least three times and has not succeeded for at least two weeks.	Display end-user message.	It looks like your data from {…} cannot be imported. We are working to resolve the issue.
11	DISCONTINUED	The connection to this financial institution is no longer available.	Display end-user message.	Connections to this institution are no longer supported. You may create a manual account and use manual transactions to track data for this account.
12	CLOSED	The end user, MX, the client, or a partner has marked the member as closed.	Display end-user message.	This connection has been closed. You may track this account manually. If reopened, you may connect the institution again.
13	DELAYED	Aggregating the member has taken longer than expected and it has not yet been connected.	Display end-user message; poll for a status update.	Importing your data from {…} may take a while. Please check back later.
14	FAILED	Aggregation failed without being connected.	Display end-user message; try aggregating again later.	There was a problem validating your credentials with {…}. Please try again later.
15	UPDATED	The member has been updated — i.e., credentials have been updated — but it has not yet been connected.	Aggregate the member once the end user logs in; poll for a status update.	Connecting to {…} …
16	DISABLED	Aggregation has been momentarily paused, but the member is still connected.	Display end-user message.	Importing data from this institution has been disabled. Please contact us if you believe it has been disabled in error.
17	IMPORTED	MX does not have credentials and will not try to aggregate the member until the end user provides credentials.	Display end-user message; re-aggregate after the end user updates credentials.	You must re-authenticate before your data can be imported. Please enter your credentials for {…}.
18	RESUMED	The answer to an MFA challenge was received, but it is not yet clear whether it was correct.	Poll for a status update.	Connecting to {…} …
19	EXPIRED	The MFA answer was not provided within the time allotted by the financial institution.	Display end-user message; re-aggregate the member if the end user initiates it.	The answer or answers were not provided in time. Please try again.
20	IMPAIRED	The member is missing some or all credentials needed in order to connect.	Display end-user message; re-aggregate after the end user updates credentials.	You must re-authenticate before your data can be imported. Please enter your credentials for {…}.
21	PENDING	The member is using OAuth to authenticate credentials and still needs to go through the financial institution’s OAuth process. A `PENDING` status will appear only on members less than one hour old with `is_oauth: true`. Members that stay `PENDING` longer than one hour will be deleted by MX.	Redirect the end user to the `oauth_window_uri` provided in the create member response, or request one through the generate OAuth window URI endpoint.	None.

1. Search for an institution

2. Get institution required credentials

3. Create a member

4. Poll the member status

1. Check the member’s connection status

2. Aggregate the member

3. Check the connection status again

4. Answer MFA with the resume aggregation endpoint

5. Check the connection status again

Test credentials for MX Bank

Testing with MXBank and OAuth

List accounts for a member

List accounts for a user

List transactions by account

Read an account

Create an MX Connect URL

List holdings for a user

List holdings for a member

List holdings for an account

Read a holding

List institutions

List institution credentials

Read an institution

Identify

Read account owners

Create a member

List members

Read a member

Update a member

Delete a member

Aggregate a member

Read a member’s connection status

Read a member’s MFA challenges

Resume aggregation from MFA

List a member’s credentials

List a member’s accounts

List a member’s transactions

Read a merchant

Extend transaction history

List transactions for a user

List transactions by account

Read a transaction

Categorize transactions

Create a user

List users

Read a user

Update a user

Delete a user

Verify

Read account numbers

Was this page helpful?