Overview

Identity is offered in the context of the Atrium API and relies on the resources of that RESTful API to function properly. Specifically, this means following the general workflow below:

1. Creating a user;
2. Creating a member using the correct institution code and credentials required by that institution; set skip_aggregation to true;
3. Polling the member’s connection_status and answering MFA if necessary;
4. Reading the member’s account_owners (you may begin with this step for members that already exist);
5. Calling the identify endpoint, if needed;
6. Repeating steps 3 and 4.

If an identification is already running, a 202 Accepted status will be returned. If another aggregation-type process is already running — like standard aggregation or extended transaction history — a 409 Conflict will be returned.

For more information on other aggregation-type processes, please see our developer guide

For important information on errors, standards and conventions, and resource structure in Atrium, please see our technical reference page.

1. Create a user

For further details on users, click here.

Endpoint:

POST /users

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\"}"
  }
}

2. Get the institution code

Only certain institutions support identification. To get a list of all institutions which support identification, append the following query string to your request URL: supports_account_identification=true.

For further details on institutions, click here.

Endpoint:

GET /institutions

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/institutions?name=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
14
15
16
17
18
19
20
21
{
  "institutions": [
    {
      "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"
    }
  ],
  "pagination": {
    "current_page": 1,
    "per_page": 25,
    "total_entries": 1,
    "total_pages": 1
  }
}

3. Get the institution's required credentials using the institution code

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"
        }
    ]
}

4. Create a member using the institution code and the required credentials

Creating a member automatically starts a standard aggregation unless the skip_aggregation parameter is set to true. On already-existing members, you can use the identify endpoint described below.

For further details on members, click here

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"
  }
}

5. Poll the connection status

A connection status of CONNECTED means that the member was successfully authenticated and aggregation has begun. The is_being_aggregated field will tell you whether aggregation has completed; the field will be true while aggregation is taking place and returns to false when aggregation is complete.

If the aggregation has triggered MFA, the response will contain a field called challenges which contains an array of MFA questions that must be answered. There are several different types of challenges, each of which has an example to the right.

For further information on connection_status and related fields, click here.

Endpoint:

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

Example request

1
2
3
4
$ curl -i 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/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"
        }
    ]
}

6. Answer MFA, if necessary

If the connection_status returns as CHALLENGED during polling, it will be necessary to answer multi-factor authentication in order to continue. This requires calling the list member MFA challenges endpoint and the resume aggregation from MFA endpoint, then polling the connection_status again.

Further details on MFA, see our technical reference or our troubleshooting guide.

Endpoint:

PUT /users/{user_guid}/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"
  }
}

7. Identify the member

The identify endpoint begins an identification process for an already-existing member.

Endpoint:

POST /users/{user_guid}/members/{member_guid}/identify

Example request

1
2
3
4
5
curl -i -X POST 'https://vestibule.mx.com/users/{user_guid}/members/{member_guid}/identify' \
  -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
16
{
  "member": {
    "aggregated_at": "2018-06-25T20:04:19Z",
    "connection_status": "CONNECTED",
    "guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
    "identifier": "chase_ds",
    "institution_code": "6930ee63-16b3-fc5e-ab48-18bbc39379d0",
    "is_being_aggregated": true,
    "is_oauth": false,
    "metadata": null,
    "name": "chase ds",
    "status": "INITIATED",
    "successfully_aggregated_at": "2018-06-25T19:45:01Z",
    "user_guid": "USR-fa7537f3-48aa-a683-a02a-b18940482f54"
  }
}

8. List the account owners

Endpoint:

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
using System;
using Atrium.Api;
using Atrium.Model;

namespace Example
{
    public class ListAccountOwnersExample
    {
        public void main()
        {
            var client = new AtriumClient("YOUR_API_KEY", "YOUR_CLIENT_ID");

            var memberGuid = "MBR-123";  // string | The unique identifier for a `member`.
            var userGuid = "USR-123";  // string | The unique identifier for a `user`.

            try
            {
                // List member account owners
                AccountOwnersResponseBody response = client.identity.ListAccountOwners(memberGuid, userGuid);
                Console.WriteLine(response);
            }
            catch (Exception e)
            {
                Console.WriteLine("Exception when calling IdentityApi.ListAccountOwners: " + e.Message );
            }
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
package main

import (
  "context"
  "fmt"
  "github.com/mxenabled/atrium-go"
)

func main() {
  client := atrium.AtriumClient("YOUR_API_KEY", "YOUR_CLIENT_ID")
  ctx := context.Background()

  memberGUID := "MBR-123" // string | The unique identifier for a `member`.
  userGUID := "USR-123" // string | The unique identifier for a `user`.

  response, _, err := client.Identity.ListAccountOwners(ctx, memberGUID, userGUID)
  if err != nil {
    fmt.Printf("Error: %v\n", err)
  } else {
    fmt.Printf("Response: %s\n", response)
  }
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
import com.mx.atrium.*;
import com.mx.model.*;

public class IdentityApiExample {
    public static void main(String[] args) {
        AtriumClient client = new AtriumClient("YOUR_API_KEY", "YOUR_CLIENT_ID");

        String memberGuid = "MBR-123"; // String | The unique identifier for a `member`.
        String userGuid = "USR-123"; // String | The unique identifier for a `user`.

        try {
            AccountOwnersResponseBody response = client.identity.listAccountOwners(memberGuid, userGuid);
            System.out.println(response);
        } catch (ApiException e) {
            System.err.println("Exception when calling IdentityApi#listAccountOwners");
            e.printStackTrace();
        }
    }
}

1
2
3
4
5
6
7
8
9
10
11
12
var atrium = require('./atrium.js');

var client = new atrium.AtriumClient("YOUR_API_KEY", "YOUR_CLIENT_ID");

var memberGuid = "MBR-123"; // string | The unique identifier for a `member`.
var userGuid = "USR-123"; // string | The unique identifier for a `user`.

var response = client.identity.listAccountOwners(memberGuid, userGuid);

response.then(function(value) {
  console.log(value);
});

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<?php
require_once(__DIR__ . '/vendor/autoload.php');

$client = new atrium\Api\AtriumClient(
    "YOUR_API_KEY",
    "YOUR_CLIENT_ID",
    new GuzzleHttp\Client()
);

$member_guid = "MBR-123"; // string | The unique identifier for a `member`.
$user_guid = "USR-123"; // string | The unique identifier for a `user`.

try {
    $result = $client->identity->listAccountOwners($member_guid, $user_guid);
    print_r($result);
} catch (Exception $e) {
    echo 'Exception when calling IdentityApi->listAccountOwners: ', $e->getMessage(), PHP_EOL;
}
?>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
from __future__ import print_function
import time
import atrium
from atrium.rest import ApiException
from pprint import pprint

# create an instance of the AtriumClient
client = atrium.AtriumClient("YOUR_API_KEY", "YOUR_CLIENT_ID")

member_guid = "MBR-123" # str | The unique identifier for a `member`.
user_guid = "USR-123" # str | The unique identifier for a `user`.

try:
    # List member account owners
    response = client.identity.list_account_owners(member_guid, user_guid)
    pprint(response)
except ApiException as e:
    print("Exception when calling IdentityApi->list_account_owners: %s\n" % e)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# load the gem
require 'atrium-ruby'

client = Atrium::AtriumClient.new("YOUR_API_KEY", "YOUR_CLIENT_ID")

member_guid = "MBR-123" # String | The unique identifier for a `member`.
user_guid = "USR-123" # String | The unique identifier for a `user`.

begin
  #List member account owners
  response = client.identity.list_account_owners(member_guid, user_guid)
  p response
rescue Atrium::ApiError => e
  puts "Exception when calling IdentityApi->list_account_owners: #{e}"
end

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
{
  "account_owners": [
    {
      "guid": "ACO-123",
      "user_guid": "USR-123",
      "member_guid": "MBR-123",
      "account_guid": "ACT-123",
      "owner_name": "Donnie Darko",
      "address": "123 This Way",
      "city": "Middlesex",
      "state": "VA",
      "postal_code": "00000-0000",
      "country": "US",
      "email": "donnie@darko.co",
      "phone": "555-555-5555"
    },
    {
      "guid": "ACO-456",
      "user_guid": "USR-123",
      "member_guid": "MBR-123",
      "account_guid": "ACT-123",
      "owner_name": "Susan Darko",
      "address": "456 That Way",
      "city": "Middlesex",
      "state": "VA",
      "postal_code": "00000-0000",
      "country": "US",
      "email": "susan@darko.co",
      "phone": "555-555-5555"
    }
  ],
  "pagination": {
    "current_page": 1,
    "per_page": 25,
    "total_entries": 2,
    "total_pages": 1
  }
}

Testing identification

To test your setup without incurring the cost of calling the identify endpoint, Atrium has test endpoints available.

Simply modify the URL to contain the user GUID test_atrium and the member GUID test_atrium_member.

The endpoint URLs will then be as follows:

/users/test_atrium/members/test_atrium_member/identify

/users/test_atrium/members/test_atrium_member/account_owners

Changelog

June 16, 2021

• Updated:
  1. The examples for the read merchant location endpoint were incorrect, and have been corrected.
• Removed:
  1. Removed the list merchant locations endpoints that was erroneously documented.

March 15, 2021

• Removed:
  1. Removed documentation in the list member credentials endpoint of functionality that was never implemented in this API.

February 11, 2021

• Added:
  1. Documented the new member field is_oauth.

February 5, 2021

• Added:
  1. Documented the new insurance-related fields on the accounts resource: insured_name, pay_out_amount, and premium_amount.

January 29, 2021

• Updated:
  1. A new default flow for account verification was documented in both the main reference and the verification guide.

December 16, 2020

• Updated:
  1. The definitions of the from_date and to_date query parameters were clarified and moved into a table for all endpoints which return lists of transactions.

December 1, 2020

• Added:

1. Documentation on the is_subscription field for the transaction resource.

November 24, 2020

• Added:
  1. Documentation on the generate OAuth URI endpoint.

November 5, 2020

• Added:
  1. Identify and verify endpoints now include the optional include_transactions parameter.

October 7, 2020

• Changed:
  1. Updated information on identification and verification to remove mention of standard aggregation as part of the workflow. Change made in technical reference as well as the guides for verification and identification.

August 3. 2020

• Added:
  1. The new mx/connect/oauthError postMessage(v4) event.

June 25. 2020

• Added:
  1. The addManualAccount step to the stepChange postMessage event.

May 11. 2020

• Changed:
  1. Reorganized the step-by-step guides for creating members and aggregating members on the “Getting Started” page.

May 1, 2020

• Added
  1. Create member and update member requests now support the optional background_aggregation_is_disabled parameter.

April 27, 2020

• Added
  1. The color_scheme configuration options for connect.

April 24, 2020

• Added
  1. Documentation on the balance type for the member data updated webhook.

April 23, 2020

• Added:
  1. The valid range for records_per_page was documented in the section on pagination.
• Changed:
  1. A broken link was fixed in the section on aggregation limits.
  2. Information on background aggregation was clarified in things you need to know and aggregate member sections.

April 22, 2020

• Added:
  1. New subtypes for accounts.

March 30, 2020

• Added:
  1. The wait_for_full_aggregation, ui_message_version, and current_institution_guid configuration options for connect.
  2. A new scenario on using the wait_for_full_aggregation configuration option.
• Changed:
  1. The “Connect Config Options” to have parity within all docs.

February 28, 2020

• Added:
  1. The institution_number and transit_number fields are now included in responses to account number requests.
  2. The list merchants endpoint was added to the API.
  3. Account balance requests must now be performed at an interval of at least two hours.

February 20, 2020

• Added:
  1. Pagination objects are now included for all cURL example responses. Pagination fields are now defined in the “Pagination” section.
• Changed:
  1. The “Things you need to know” section was reorganized for clarity.

February 7, 2020

• Added:
  1. Documented the include_transactions option for the connect widget and a scenario on how to use it.
• Changed :
  1. Reorganized the connect configuration options to be in alphabetical order and removed duplicate options.

January 14, 2019

• Changed:
  1. Improved the organization and documentation for the section on the Connect widget.
• Added:
  1. A table outlining scenarios for configuring the connect widget.

December 2, 2019

• Added:
  1. Documentation on how the logo_url field works for merchants;
  2. A warning in the things you need to know section explaining that data for every field may not always be returned.
• Changed:
  1. Reorganized the things you need to know section to make it more alphabetical, as well as clarifying some of the language;
  2. Various typos and mistakes.

November 19, 2019

• Added:
  1. Documentation on the merchant_category_code, as well as missing fields from some response examples for the cleanse and categorize endpoint.

November 12, 2019

• Changed:
  1. The response for the list MFA challenges endpoint was improperly documented, specifically for instances where type = IMAGE_OPTIONS. This has been corrected.

October 31, 2019

• Changed:
  1. Re-wrote and clarified the guide for verification, including added information on how to properly use the Connect widget with verification.

October 21, 2019

• Changed:
  1. Premium features were all grouped under their own heading, and additional clarifications about process and related errors were given.

October 20, 2019

• Added:
  1. Information on status codes to all aggregation-type endpoints: aggregate member, aggregate account balances, fetch statements, extended transaction history, verify member, and identify member.
  2. A new section to the main developer guide on how to run multiple aggregation-type processes.

October 19, 2019

• Changed:
  1. Alphabetized section headings as well as subheadings within each section.

October 18, 2019

• Added:
  1. New is_authenticated field to the read member connection status response.

October 17, 2019

• Added:
  1. New aggregate member account balances endpoint.

August 29, 2019

• Added:
  1. New advanced configuration option for Connect: disable_institution_search.

June 13, 2019

• Updated:
  1. All guides were updated to reflect the correct MFA workflow. Specifically, calling the list member challenges endpoint is not usually necessary because the read member connection status endpoint will return MFA challenges whenever the connection_status is CHALLENGED.
  2. Corrected some incorrect code examples in the guides for identity and verification.
  3. Several images were updated to reflect the correct MFA workflow.
• Added

1. A full data model was added to the read member connection status endpoint to make it clear that this response is not the same as the response to read member or list members.

June 5, 2019

• Updated:
  1. An example response in the Atrium guide contained an incorrect member status and was corrected.

May 21, 2019

• Updated:
  1. The section on webhooks now links back to the definitions for connection_status where appropriate.
  2. The example responses for the list account transactions endpoint were missing the merchant_guid field.
  3. The section on webhooks now directs developers to whitelist their own IP addresses at the appropriate portal page, rather than contacting support.
  4. Certain values for account types and subtypes were missing underscores or used dashes inappropriately.

March 21, 2019

• Added:
  1. Documentation about configuring and testing webhooks, with a link to the webhooks profile in the Atrium portal.
• Updated
  1. Rearranged the documentation on webhooks for improved clarity.

February 25, 2019

• Added:
  1. Documentation on two new webhooks: extended history and statements.

February 22, 2019

• Added:
  1. Documentation on the new download statement PDF endpoint.
  2. Documentation on the new read statement endpoint.

February 7, 2019

• Removed:
  1. Documentation related to the type parameter for aggregation events.
• Added:
  1. A new premium endpoint for gathering an extended transaction history.
  2. A new premium endpoint for fetching account statements.

January 30, 2019

• Added
  1. Documentation on new aggregation types.
  2. Documentation on the new statements endpoint.
  3. Documented two new fields for institutions: supports_transaction_history and supports_account_statements.

January 28, 2019

• Updated:
  1. The definition of the total_account_value field for accounts has been modified for clarity.
  2. The definition for connection_status field for members was updated to include the correct data type and fix a broken table.

January 11, 2019

• Added:
  1. Code examples in several new languages for the getting started guide.
  2. Code examples in several new languages for the verification guide.
  3. Code examples in several new languages for the identification guide.

December 18, 2018

• Added:
  1. Documentation for the new holdings endpoints and associated resources.

December 12, 2018

• Added:
  1. Documentation for the merchants endpoint.
  2. Merchant GUIDs are now returned in responses for the cleanse and categorize endpoint.
• Fixed
  1. A number of typos and broken links were addressed.

November 26, 2018

• Added:
  1. The display_order field was added to both institution credentials and member credentials.

November 19, 2018

• Added the fields supports_account_verification and supports_account_identification to the institution resource.
• Added the ability to search institutions according to whether they support identity and/or verification.
• Clarified that the limit of 25 members per user applies to all environments, not just the development environment.

November 16, 2018

• Added:
  1. Documentation for Atrium webhooks.

September 20, 2018

• Added:
  1. Added a warning about getting 403 errors for identity and/or verification even when these premium features are enabled on an institution.
• Changed
  1. Clarified information about the necessity of having MX enable premium features before they can be used, as well as error messages when they are not enabled.

August 13, 2018

• Added:
  1. Ruby code examples for all endpoints related to both identity and verification in both the technical reference and the guides.
  2. The currency_code field on accounts and transactions.
  3. Information on IP address whitelisting.

July 20, 2018

• Added:
  1. Documentation for the verify and account numbers endpoints under the new section on account verification.
  2. Documentation for the identify and account owners endpoints under the new section on identity verification.
  3. A guide to using Atrium Identity Verification.
  4. A guide to using Atrium Account Verification.

April 25, 2018

Updated support escalation information in the Member statuses section of the Getting Started with Atrium guide.

April 20, 2018

• Added the is_international field to the specification for transactions, as well as related code examples.

March 6, 2018

• Added a new page entitled “Getting started with Atrium” containing information on common questions, workflows, procedures, etc. to help developers get going with the API as fast as possible.

February 14, 2018

Added code examples for several languages.

December 5, 2017

• Member connection statuses have been taken out of beta. The section on reading the member status has been updated to reflect this.
• The new is_being_aggregated field was added to facilitate the use of member connection statuses.

November 21, 2017

• Fixed a mistake that resulted in listing the Investments categories as subcategories of Income.

October 4, 2017

• Added documentation on the new list member credentials endpoint.
• Updated the “next steps” column on the table under read member status to reflect the new flow when using the list member credentials endpoint.

September 13, 2017

• Complete site redesign and documentation rewrite.
• Added images to show correct aggregation workflow
• Added change log to documentation
• Added section on Beta member connection statuses