Skip to main content

Migration Guide

This guide covers all breaking changes across Platform API versions in reverse chronological order. Find your current version and follow each section forward to reach the latest version.

Migrating from v20250224 to rc20260430​

info

Jump to your starting point:

rc20260430 redesigns how the Platform API structures responses for key resources, adds new capabilities for merchant intelligence and enables secure data sharing. The two primary drivers behind this version:

  1. Data minimization — Responses for specific resources are slimmer by default. Resources targeted in this release: members, accounts, transactions, rewards, statements, account owners, account numbers, and member status. Related data is available through the new Layered Responses model.
  2. Enhanced merchant coverage — Dramatically improved merchant intelligence: assignments now carry confidence levels, and a new counterparties includes captures all parties in a transaction.

Non-breaking changes​

Alongside breaking changes, rc20260430 introduces new features and enhancements:

  • Layered Responses — A three-tier response architecture (Base → Companions → Includes) that gives you control over payload size. See Layered Responses.
  • Enhanced merchant data — Confidence levels on merchant assignments and a new counterparties includes for multi-merchant transactions. See Includes.
  • Data Exchange — A new set of endpoints for secure client-to-client financial data sharing. Issuers grant access to grantees via client grants; grantees exchange grants for tokens and access namespaced Data Exchange endpoints. See Third Party Data Exchange for the full workflow and endpoint reference.
  • self field — Overhauled resources now include a self URI pointing to their own detail endpoint. Follow self links from list responses instead of constructing URIs manually.

Breaking changes​

These are the minimum changes required to migrate from v20250224 to rc20260430.

  1. Update your version header. Change Accept-Version to rc20260430 on all requests. See Request headers.
  2. Update response parsing. Responses for members, accounts, transactions, rewards, statements, account owners, account numbers, and member status now return fewer top-level fields. Related resource data has moved into companion objects (e.g., user_guid is now user.guid). See Layered Responses.
  3. Update the includes query parameter. The includes parameter changes from a string to an array (includes[]) with new supported values: merchant, counterparties, category, and repeating_transaction. Previous values are no longer accepted. See Includes.
  4. Update the member create request body. The request body for creating members has been restructured. See Member create changes.
  5. Replace the OAuth URI endpoint. GET /oauth_window_uri is replaced by POST /oauth/authorization_url. See OAuth authorization endpoint changes.
  6. Remove skip_aggregation. This field was deprecated in v20250224 and is removed in rc20260430. Use data_request.products instead. See Aggregation endpoints.
  7. Update aggregation response handling. Aggregation endpoints have new paths and now return the member_status response instead of the member response. The member_status response has been overhauled with a new products companion, and several fields have been renamed (aggregated_at is now last_attempted_at, successfully_aggregated_at is now last_updated_at), etc. See Aggregation endpoints.
  8. Revert date filters to ISO 8601. The Unix timestamps introduced in v20250224 for date query parameters are reverted to ISO 8601 strings. See Date format changes.

Layered Responses​

The Layered Responses model structures API responses in three types of data: Base, Companion and Includes. You get the base by default, companions always accompany full resource requests, and includes require explicit opt-in.

Layer 1: Base Response​

Every resource has a core set of fields that comprise the Base response. All optimized Platform API responses for a resource or which reference a resource will include the fields defined in the Base response.

Base characteristics:

  • Contains MX and partner identifiers for the resource.
  • Resource-specific attributes such as the balance for an Account or the amount for a Transaction.
  • A self link (URI) to the resource's Read endpoint. Simplify integrations by utilizing this link instead of constructing URIs manually.

The base is what you see when a resource appears as a companion inside another resource. A member's base on an account response is structurally identical to a member's base when fetched directly. This consistency is central to how the Layered Responses model works.

Layer 2: Full Resource Response (Base + Companions)​

When you request a resource directly (e.g., GET /users/{user_guid}/members/{member_guid}), you receive the base and all Companions (related resources such as the member and user on an Account response).

Companion characteristics:

  • Always present (not opt-in) on full resource endpoints.
  • Always in base form (never nested more than one level deep).
  • Resources persisted by MX contain an mx_record.

mx_record: Contains created_at and updated_at timestamps (UTC, ISO 8601). Present on all resources that correspond to persisted records, absent on representational sub-resources like member_status.

  • These timestamps represent when the record was created or last modified within the MX platform, not when the underlying resource itself was created. For example, an account.mx_record.created_at does not indicate when the account was originally opened at the institution. It indicates when that account was first recorded on the platform.

Read Member response (GET /users/{user_guid}/members/{member_guid}):

In this response, guid, id, metadata, name, and self are the member's Base fields. The remaining keys (institution, user, member_status, oauth, mx_record) are the Companions.


_34
{
_34
"member": {
_34
"guid": "MBR-7c6f361b-e582-15b6-60c0-358f12466b4b",
_34
"id": "member-1234",
_34
"metadata": "\"credentials_last_refreshed_at\": \"2015-10-15\"",
_34
"name": "MX Bank",
_34
"self": "/users/USR-.../members/MBR-...",
_34
"institution": {
_34
"code": "mx_bank",
_34
"guid": "INS-123",
_34
"name": "MX Bank",
_34
"self": "/institutions/INS-123"
_34
},
_34
"user": {
_34
"guid": "USR-11141024-90b3-1bce-cac9-c06ced52ab4c",
_34
"id": "U-201709221210",
_34
"self": "/users/USR-..."
_34
},
_34
"member_status": {
_34
"status": "CHALLENGED",
_34
"error": { "error_type": "AUTHENTICATION", "..." : "..." },
_34
"self": "/users/USR-.../members/MBR-.../status"
_34
},
_34
"oauth": {
_34
"is_oauth": true,
_34
"authorization_url": "https://mxbank.mx.com/oauth/authorize?...",
_34
"self": "/users/USR-.../members/MBR-.../oauth/authorization_url"
_34
},
_34
"mx_record": {
_34
"created_at": "2024-03-15T10:30:00.000Z",
_34
"updated_at": "2025-06-01T14:22:00.000Z"
_34
}
_34
}
_34
}

Layer 3: Includes (Opt-In Data)​

Additional response data can be accessed using the includes[] query parameter.

List Transactions example


_10
GET /users/{user_guid}/accounts/{account_guid}/transactions?includes[]=merchant&includes[]=counterparties

Note: Includes keys are absent from the response entirely unless requested. When requested but no data exists, the value is null. See the individual endpoint documentation for more information.

Identifier relocation​

Related resource identifiers moved from top-level fields into Companion objects. Fields like user_guid and institution_code no longer exist at the top level. Instead, access them through their companion: user.guid, institution.code.

Before (v20250224):


_10
{
_10
"member": {
_10
"guid": "MBR-...",
_10
"user_guid": "USR-123",
_10
"institution_code": "mxbank"
_10
}
_10
}

After (rc20260430):


_14
{
_14
"member": {
_14
"guid": "MBR-...",
_14
"user": {
_14
"guid": "USR-123",
_14
"self": "/users/USR-123"
_14
},
_14
"institution": {
_14
"code": "mxbank",
_14
"guid": "INS-123",
_14
"self": "/institutions/INS-123"
_14
}
_14
}
_14
}

Resource response changes​

rc20260430 significantly reduces the number of top-level fields on the resources listed below. Responses now return only base fields and companions as described in Layered Responses. Fields that are not part of the base or companion structure have been removed from the default response.

Removed fields are not permanently gone

Fields removed from the default response are not deleted from the platform. In upcoming releases MX will reintroduce removed fields reorganized into opt-in objects.

We are actively partnering with clients to prioritize field reintroduction. If your integration depends on a removed field, contact your MX representative or reach out to [PLACEHOLDER — TBD].

For full response schemas and examples, see the endpoint documentation linked below for each resource.

Account​

Reduced from ~50 fields to 8 base fields + companions. See Accounts endpoint documentation for the full response schema.

Change typeField
Renamedaccount_number → account_number_display
Relocateduser_guid → user.guid
user_id → user.id
member_guid → member.guid
member_id → member.id
Removedaccount_ownership, annuity_policy_to_date, annuity_provider, annuity_term_year, apr, apy, available_balance, available_credit, balance, cash_balance, cash_surrender_value, created_at, credit_limit, currency_code, day_payment_is_due, death_benefit, federal_insurance_status, imported_at, interest_rate, institution_code, insured_name, is_closed, is_hidden, is_manual, last_payment, last_payment_at, loan_amount, margin_balance, matures_on, member_is_managed_by_user, metadata, minimum_balance, minimum_payment, original_balance, pay_out_amount, payment_due_at, payoff_balance, premium_amount, property_type, routing_number, started_on, statement_balance, today_ugl_amount, today_ugl_percentage, total_account_value, total_account_value_ugl, updated_at
Addedself, member companion, mx_record companion

Account number​

Account number fields have been restructured from flat values to nested objects grouped by payment network. ach and eft are nullable (only populated when applicable). See Account Numbers endpoint documentation for the full response schema.

Change typeField
Restructuredaccount_number, routing_number → ach.account_number, ach.routing_number
institution_number, transit_number → eft.institution_number, eft.transit_number
Relocatedaccount_guid → account.guid
member_guid → member.guid
user_guid → user.guid
Removedloan_guarantor, loan_reference_number, passed_validation, sequence_number
Addedaccount companion, member companion

_10
{
_10
"account_number": {
_10
"guid": "ACN-...",
_10
"ach": { "account_number": "3331261", "routing_number": "68899990000000" },
_10
"eft": null,
_10
"account": { "guid": "ACT-...", "name": "...", "self": "..." },
_10
"member": { "guid": "MBR-...", "name": "...", "self": "..." },
_10
"user": { "guid": "USR-...", "id": "U-123", "self": "/users/USR-..." }
_10
}
_10
}

Account owner​

Account owner fields have been restructured from flat values to arrays, supporting multiple names, addresses, phone numbers, and emails per owner. This is a structural change, not just field relocation. See Account Owners endpoint documentation for the full response schema.

Change typeField
Restructuredowner_name, first_name, last_name → names[] array of { name, first_name, last_name }
address, city, state, postal_code, country → addresses[] array of { street, city, state, postal_code, country }
phone → phone_numbers[] array of { phone }
email → emails[] array of { email }
Relocatedaccount_guid → account.guid
member_guid → member.guid
user_guid → user.guid
Addedaccount companion, member companion

_12
{
_12
"account_owner": {
_12
"guid": "ACO-...",
_12
"names": [{ "name": "Josh Smith", "first_name": "Josh", "last_name": "Smith" }],
_12
"addresses": [{ "street": "3541 Adrian Street", "city": "Middlesex", "state": "VA", "postal_code": "00000-0000", "country": "US" }],
_12
"phone_numbers": [{ "phone": "555-555-5555" }],
_12
"emails": [{ "email": "example@example.com" }],
_12
"account": { "guid": "ACT-...", "name": "...", "self": "..." },
_12
"member": { "guid": "MBR-...", "name": "...", "self": "..." },
_12
"user": { "guid": "USR-...", "id": "U-123", "self": "/users/USR-..." }
_12
}
_12
}

Member​

Reduced from ~25 fields to 5 base fields + companions. See Members endpoint documentation for the full response schema.

Change typeField
Renamedaccount_number → account_number_display
Relocateduser_guid → user.guid
user_id → user.id
institution_code → institution.code
institution_guid → institution.guid
connection_status → member_status.status
oauth_window_uri → oauth.authorization_url
Removedaggregated_at, background_aggregation_is_disabled, connection_status_message, is_being_aggregated, is_managed_by_user, is_manual, is_oauth, most_recent_job_detail_code, most_recent_job_detail_text, most_recent_job_guid, needs_updated_credentials, successfully_aggregated_at, use_cases
Addedself, institution companion, member_status companion, oauth companion, mx_record companion

Member status​

The most significantly restructured resource. The response envelope key changes from member to member_status. A new products companion provides per-product support status and replaces several renamed fields. Aggregation endpoints now return this member_status response instead of the member response.

v20250224 fieldrc20260430 equivalent
Response key: memberResponse key: member_status
connection_statusstatus (base)
aggregated_atproducts.last_attempted_at
successfully_aggregated_atproducts.last_updated_at
guidmember.guid (companion)
has_processed_accountsRemoved
has_processed_transactionsRemoved
has_processed_account_numbersRemoved
is_authenticatedRemoved
is_being_aggregatedRemoved

_21
{
_21
"member_status": {
_21
"status": "CONNECTED",
_21
"error": null,
_21
"self": "/users/USR-.../members/MBR-.../status",
_21
"challenges": [],
_21
"member": { "guid": "MBR-...", "id": null, "name": "MX Bank", "self": "..." },
_21
"products": {
_21
"last_attempted_at": "2025-01-13T17:57:38Z",
_21
"last_updated_at": "2025-01-13T17:57:38Z",
_21
"account_verification": { "is_supported": true },
_21
"identity_verification": { "is_supported": true },
_21
"transactions": { "is_supported": true },
_21
"transaction_history": { "is_supported": true },
_21
"statements": { "is_supported": true },
_21
"investments": { "is_supported": false },
_21
"rewards": { "is_supported": false }
_21
},
_21
"user": { "guid": "USR-...", "id": "U-123", "self": "/users/USR-..." }
_21
}
_21
}

Rewards​

Reduced from ~8 fields to 5 base fields + companions. See Rewards endpoint documentation for the full response schema.

Change typeField
Relocatedaccount_guid → account.guid
member_guid → member.guid
user_guid → user.guid
Removedbalance_type, created_at, expires_on, updated_at
Addedself, account companion, member companion, mx_record companion

Statement​

Reduced from ~8 fields to 3 base fields + companions. See Statements endpoint documentation for the full response schema.

Change typeField
Relocatedaccount_guid → account.guid
member_guid → member.guid
user_guid → user.guid
created_at → mx_record.created_at
updated_at → mx_record.updated_at
Addedaccount companion, member companion, mx_record companion

Transaction​

Reduced from ~40 fields to 9 base fields + companions. List and Read Transaction endpoints also support opt-in includes[]. Create Transaction does not. See Transactions endpoint documentation for the full response schema.

Change typeField
Relocatedaccount_guid → account.guid
account_id → account.id
member_guid → member.guid
user_guid → user.guid
user_id → user.id
category → category.name (include)
category_guid → category.guid (include)
merchant_guid → merchant.guid (include)
Removedcheck_number_string, created_at, extended_transaction_type, is_bill_pay, is_direct_deposit, is_expense, is_fee, is_income, is_international, is_manual, is_overdraft_fee, is_payroll_advance, is_recurring, is_subscription, latitude, localized_description, localized_memo, longitude, member_is_managed_by_user, memo, merchant_category_code, merchant_location_guid, metadata, original_description, posted_at, top_level_category, transacted_at, updated_at
Addedself, account companion, member companion, mx_record companion

See Includes for changes to the includes[] query parameter on List/Read Transaction endpoints.

Includes​

The includes query parameter changes from a comma-separated string to an array format, and the set of accepted values has changed. The includes query parameter is currently available on List and Read Transaction endpoints. Support for additional endpoints is planned for future releases.

Syntax change:

Before (v20250224):


_10
GET /users/{user_guid}/transactions?includes=merchants,geolocations

After (rc20260430):


_10
GET /users/{user_guid}/transactions?includes[]=merchant&includes[]=counterparties

Value changes:

v20250224 valuerc20260430 equivalent
merchantsmerchant
repeating_transactionsrepeating_transaction
geolocationsRemoved
classificationsRemoved
--category (new)
--counterparties (new)

When an includes is requested but no data exists for the transaction, the value is null. Include keys are absent from the response entirely unless requested.

Enhanced merchant data​

The merchant includes returns a confidence_level field indicating match quality (e.g., "Very High" or "Low"). This replaces the previous all-or-nothing merchant assignment with a confidence-based model.

Counterparties​

counterparties is a new includes that returns all parties involved in a transaction. This is distinct from the merchant includes, which returns only the primary merchant.

For example, ordering McDonald's through DoorDash:

  • merchant = DoorDash (the payment processor)
  • counterparties = [DoorDash, McDonald's] (all involved parties)

Each counterparty includes guid, name, confidence_level, logo_url, website_url, and self.

Member create changes​

The request body for creating a member has been restructured. OAuth-related fields (client_redirect_url, enable_app2app, referral_source, ui_message_webview_url_scheme) have moved from the top level of the request body into a new oauth object. The skip_aggregation field, deprecated in v20250224, is removed entirely. Use data_request.products to control which products aggregate on member creation.

Before (v20250224):


_17
{
_17
"client_redirect_url": "https://example.com/callback",
_17
"enable_app2app": true,
_17
"referral_source": "APP",
_17
"ui_message_webview_url_scheme": "mx",
_17
"member": {
_17
"institution_code": "mxbank",
_17
"credentials": [
_17
{ "guid": "CRD-1234", "value": "username" },
_17
{ "guid": "CRD-5678", "value": "password" }
_17
],
_17
"skip_aggregation": false
_17
},
_17
"data_request": {
_17
"products": ["transactions", "identity_verification"]
_17
}
_17
}

After (rc20260430):


_18
{
_18
"member": {
_18
"institution_code": "mxbank",
_18
"credentials": [
_18
{ "guid": "CRD-1234", "value": "username" },
_18
{ "guid": "CRD-5678", "value": "password" }
_18
]
_18
},
_18
"oauth": {
_18
"client_redirect_url": "https://example.com/callback",
_18
"enable_app2app": true,
_18
"referral_source": "APP",
_18
"ui_message_webview_url_scheme": "mx"
_18
},
_18
"data_request": {
_18
"products": ["transactions", "identity_verification"]
_18
}
_18
}

ChangeDetail
client_redirect_urlMoved to oauth.client_redirect_url
enable_app2appMoved to oauth.enable_app2app
referral_sourceMoved to oauth.referral_source
ui_message_webview_url_schemeMoved to oauth.ui_message_webview_url_scheme
skip_aggregationRemoved. Use data_request.products

The member and data_request objects are unchanged. See the Create Member endpoint documentation for the full request schema.

OAuth authorization endpoint changes​

The OAuth authorization URL endpoint changes from a GET with query parameters to a POST with a request body. The new endpoint path and body structure align with the member create request body.

Before (v20250224):


_10
GET /users/{user_guid}/members/{member_guid}/oauth_window_uri
_10
?client_redirect_url=https://example.com/callback
_10
&referral_source=APP
_10
&enable_app2app=true
_10
&ui_message_webview_url_scheme=mx

After (rc20260430):


_10
POST /users/{user_guid}/members/{member_guid}/oauth/authorization_url


_11
{
_11
"oauth": {
_11
"client_redirect_url": "https://example.com/callback",
_11
"enable_app2app": true,
_11
"referral_source": "APP",
_11
"ui_message_webview_url_scheme": "mx"
_11
},
_11
"data_request": {
_11
"products": ["transactions", "identity_verification"]
_11
}
_11
}

Both oauth and data_request are optional. If provided, neither can be empty.

The response envelope key changes from member to oauth and includes a member companion and user companion. See the Create OAuth Authorization URL endpoint documentation for the full request and response schemas.

Aggregation endpoints​

Aggregation endpoints have been renamed to align with the product names used in data_request.products. The old paths are deprecated in rc20260430 and will be removed in the next version. All aggregation endpoints now return the member_status response instead of the member response (see Member status for the response structure).

All paths are relative to /users/{user_identifier}/members/{member_identifier}/.

v20250224 pathrc20260430 path
.../aggregate.../transactions (POST)
.../check_balance.../account_balances (POST)
.../extend_history.../transaction_history (POST)
.../identify.../identity_verification (POST)
.../verify.../account_verification (POST)
.../fetch_statements.../statements (POST)
.../fetch_rewards.../rewards (POST)

Date format changes​

The Unix timestamp format introduced in v20250224 for transaction date query parameters is reverted to ISO 8601 date strings (YYYY-MM-DD) in rc20260430.

Before (v20250224):


_10
GET /users/{user_guid}/transactions?from_date=1704067200&to_date=1706745600

After (rc20260430):


_10
GET /users/{user_guid}/transactions?from_date=2024-01-01&to_date=2024-02-01

This applies to all date filter parameters on List Transaction endpoints: from_date, to_date, from_created_at, to_created_at, from_updated_at, to_updated_at.

Migrating from v20111101?

If you are migrating directly from v20111101, no date format change is needed. v20111101 already uses ISO 8601 date strings, and rc20260430 continues using the same format.

Deprecated endpoints​

The following endpoints are deprecated in rc20260430. They remain functional but will be removed in the next version. Migrate to the replacement endpoints listed below.

All paths below are member scoped relative to /users/{user_identifier}/members/{member_identifier}/....

Deprecated endpointReplacement
GET .../oauth_window_uriPOST .../oauth/authorization_url (details)
POST .../aggregatePOST .../transactions
POST .../check_balancePOST .../account_balances
POST .../extend_historyPOST .../transaction_history
POST .../identifyPOST .../identity_verification
POST .../verifyPOST .../account_verification
POST .../fetch_statementsPOST .../statements
POST .../fetch_rewardsPOST .../rewards

For aggregation endpoint details, see Aggregation endpoints.

Sunset endpoints​

The managed institution and managed member endpoints that were deprecated in v20250224 are fully sunset in rc20260430 and no longer functional. Requests to these endpoints return 410 Gone.

  • GET /managed_institutions
  • GET|POST /users/{user_guid}/managed_members
  • GET|PUT /users/{user_guid}/managed_members/{member_guid}
  • GET|POST /users/{user_guid}/managed_members/{member_guid}/accounts
  • GET|PUT /users/{user_guid}/managed_members/{member_guid}/accounts/{account_guid}
  • GET|POST /users/{user_guid}/managed_members/{member_guid}/accounts/{account_guid}/transactions

Validate your migration​

Use the MX development (INT) environment to test your migration before updating production integrations.

  1. Update your Accept-Version header to rc20260430 in your INT environment requests.
  2. Verify response parsing handles the new Layered Responses structure for each resource type your integration uses.
  3. Confirm aggregation flows work with the new endpoint paths and member_status response shape.
  4. If using includes[], verify the array syntax and new values return expected data on transaction endpoints.
  5. Test member creation and OAuth flows with the restructured request bodies.

The INT environment shares the same code base as production but uses https://int-api.mx.com as the base URL.

Migrating from v20111101 to v20250224​

info

If you're on v20111101, start here. If you're on v20250224, jump up to Migrating from v20250224 to rc20260430.

v20250224 introduced several breaking changes focused on standardizing how products are configured, modernizing request headers, and cleaning up deprecated endpoints. The numbered list below summarizes the minimum changes required.

  1. Update request headers on all API calls.
  2. Update institution queries and responses to use the new supported_products array. The following individual fields are deprecated:
    • supports_account_identification
    • supports_account_statement
    • supports_account_verification
    • supports_transaction_history
  3. Some endpoints now set products for aggregation using data_request. See Data request products array.
    • Request Widget URL endpoint: When requesting the Connect Widget URL, the following configuration parameters are no longer used in the request body:
      • mode
      • include_identity
      • include_transactions
  4. The supported_products and data_request.products arrays accept the following product values:
    • Instant Account Verification: account_verification
    • Account Owner Identification: identity_verification
    • Account Aggregation: transactions
    • Extended History: transaction_history
    • Statements: statements
    • Investments: investments
    • Rewards: rewards
  5. Managed data endpoints have been deprecated. See Deprecated endpoints.
  6. List Transactions date filter parameters changed from ISO 8601 strings to Unix timestamps. See List Transactions date filters.

Request headers​

Modify your Accept request header to application/json and add an Accept-Version header set to v20250224.

Example
Language:shell

_10
curl -L -X POST 'https://int-api.mx.com/endpoint' \
_10
-H 'Content-Type: application/json' \
_10
-H 'Accept: application/json' \
_10
-H 'Accept-Version: v20250224' \
_10
-H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}'

Unified Product Ordering​

Unified Product Ordering beta users must replace the beta header:


_10
-H 'Accept: application/vnd.mx.api.v1+json; version=v20250224'

Use the new version header:


_10
-H 'Accept: application/json'
_10
-H 'Accept-Version: v20250224'

Set products​

Supported products array​

Enhanced search and filtering capabilities based on the products supported by each institution. Uses the supported_products array. See Product values for accepted values.

List Institutions: GET /institutions

Read Institution: GET /institutions/{institution_code}

Query
Language:shell

_10
curl -X GET 'https://api.mx.com/institutions?supported_products[]=account_verification&supported_products[]=transactions' \
_10
-H 'Accept: application/json' \
_10
-H 'Accept-Version: v20250224' \
_10
-H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}'

Response
Language:json

_21
{
_21
"institution": {
_21
"code": "mxbank",
_21
"forgot_password_url": "https://example.url.mxbank.com/forgot-password",
_21
"forgot_username_url": "https://example.url.mxbank.com/forgot-username",
_21
"instructional_text": "Some instructional text ...",
_21
"iso_country_code": null,
_21
"medium_logo_url": "https://content.moneydesktop.com/storage/MD_Assets/Ipad%20Logos/100x100/default_100x100.png",
_21
"name": "MX Bank",
_21
"small_logo_url": "https://content.moneydesktop.com/storage/MD_Assets/Ipad%20Logos/50x50/default_50x50.png",
_21
"supported_products": [
_21
"account_verification",
_21
"identity_verification",
_21
"transactions",
_21
"transaction_history"
_21
],
_21
"supports_oauth": false,
_21
"trouble_signing_in_url": null,
_21
"url": "https://www.mx.com"
_21
}
_21
}

Data request products array​

Initiate the aggregation of specific products in the body of requests to create members and request Connect Widget URLs.

Create Member: POST /users/{user_guid}/members

Request Widget URL: POST /users/{user_guid}/widget_urls

Create
Language:shell

_15
curl -L -X POST 'https://int-api.mx.com/users/{user_guid}/members' \
_15
-H 'Content-Type: application/json' \
_15
-H 'Accept: application/json' \
_15
-H 'Accept-Version: v20250224' \
_15
-H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}' \
_15
--data-raw '{
_15
"member": {
_15
"institution_code": "mxbank",
_15
"is_oauth": true,
_15
"metadata": "\"credentials_last_refreshed_at\": \"2015-10-15\""
_15
},
_15
"data_request": {
_15
"products": ["account_verification", "identity_verification", "transactions"]
_15
}
_15
}'

Request
Language:shell

_13
curl -L -X POST 'https://int-api.mx.com/users/{user_guid}/widget_urls' \
_13
-H 'Content-Type: application/json' \
_13
-H 'Accept: application/json' \
_13
-H 'Accept-Version: v20250224' \
_13
-H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}' \
_13
--data-raw '{
_13
"widget_url": {
_13
"widget_type": "connect_widget"
_13
},
_13
"data_request": {
_13
"products": ["account_verification", "identity_verification", "transactions"]
_13
}
_13
}'

Use data_request.products on the Request Widget URL and Create Member endpoints instead of manually initiating aggregation when a member is first created. See Product values for accepted values.

Product values​

Product values accepted in supported_products and data_request.products arrays:

ProductValue
Instant Account Verificationaccount_verification
Account Owner Identificationidentity_verification
Account Aggregationtransactions
Extended Historytransaction_history
Statementsstatements
Investmentsinvestments
Rewardsrewards

Manually initiating aggregation​

You may continue to manually initiate data aggregation with these endpoints:

  • Aggregate Member
  • Balance Check
  • Extend History
  • Fetch Statements
  • Identify Member
  • Verify Member
note

Balance data is always included and does not need to be set.

List Transactions date filters​

In v20250224, the from_date, to_date, from_created_at, to_created_at, from_updated_at, and to_updated_at query parameters on List Transactions endpoints accept Unix timestamps instead of the ISO 8601 strings (YYYY-MM-DD) used in v20111101.

Affected endpoints:

  • GET /users/{user_identifier}/transactions
  • GET /users/{user_identifier}/members/{member_identifier}/transactions
  • GET /users/{user_guid}/accounts/{account_guid}/transactions
  • GET /users/{user_identifier}/members/{member_identifier}/accounts/{account_identifier}/transactions
  • GET /users/{user_identifier}/tags/{tag_guid}/transactions
Not recommended for adoption

This change is specific to v20250224. The next version (rc20260430) reverts these parameters back to ISO 8601 date strings to remain consistent with all other date formats in the API.

If you are migrating from v20111101 to rc20260430, you can skip this change entirely. Continue using ISO 8601 dates and proceed directly to the rc20260430 migration section.

If you are migrating to v20250224 only, be aware that you will need to revert to ISO 8601 when you eventually upgrade to rc20260430 or later.

Deprecated fields​

The skip_aggregation field is deprecated in favor of data_request.products, which provides more granular control over data aggregation. While still supported in v20250224, skip_aggregation is removed in rc20260430. Migrate to data_request.products.

The following fields in the Check Member Status endpoint response are deprecated:

  • has_processed_account_numbers
  • has_processed_accounts
  • has_processed_transactions

Deprecated endpoints​

Deprecation of these endpoints should not impact most integrations. If you have questions, please contact MX.

  • /managed_institutions
  • /users/{user_guid}/managed_members
  • /users/{user_guid}/managed_members/{member_guid}
  • /users/{user_guid}/managed_members/{member_guid}/accounts
  • /users/{user_guid}/managed_members/{member_guid}/accounts/{account_guid}
  • /users/{user_guid}/managed_members/{member_guid}/accounts/{account_guid}/transactions
  • /users/{user_guid}/managed_members/{member_guid}/accounts/{account_guid}/transactions/{transaction_guid}
Sunset in rc20260430

These managed data endpoints are fully sunset in rc20260430 and are no longer functional. If you are migrating directly to rc20260430, these endpoints are unavailable.

Sunset endpoints​

The following previously deprecated endpoints are no longer documented in v20250224:

  • /payment_processor_authorization_code
  • /users/{user_guid}/connect_widget_url
On this page