Skip to main content
A single real-world financial institution may have several institution objects on the MX platform. For example, the mortgage division of a financial institution might use a separate system than its everyday banking division, which is different from its credit card division. Only MX can create an institution. Each institution can offer multiple connection methods such as:
  • An email and a password
  • A username and a password
  • OAuth (some institutions don’t support OAuth)
When creating a member, you must also call List Institution Credentials to retrieve the set of required credentials for each institution and request them from the user. You can Read an Institution to see what products each institution supports and access an institution’s:
  • Logos
  • URLs for things such as forgotten usernames and passwords
  • Instructional text (we use this in our Connect Widget to help give further context on any caveats users may encounter when attempting to connect to the institution)
The list of institutions can change at any time.

Caching our Institutions List and Credentials

You can use the List Institutions endpoint to retrieve a list of all institutions currently available in the MX platform. To avoid frequent calls that return all supported institutions, we recommend caching the institution list and the required credentials for each institution daily. This ensures you pick up new institutions and any changes to existing ones, such as updated required credentials when MX switches to a new data provider. We aim to maintain the same institution guid even if we change data providers, but in rare cases, it may change.

Institution Fields

Status

The institution object provides two fields that clarify the status of that institution:
  • institution.status represents the global status of the institution across MX.
  • institution.client_status represents the institution status specifically for your client configuration. This allows MX tooling to apply client-level rules without affecting global institution behavior.
Use these fields to:
  • Differentiate between the institution’s overall status and the status for your specific integration.
  • Control which institutions are shown to users based on these status values.
  • Display clearer messages to your users when an institution is unavailable, has known issues, or is otherwise restricted.
Use the following workflow to provide clearer messaging around institution status to end users:
  1. Update your institution-related API integrations to read status and client_status where applicable.
  2. Map each relevant status value to appropriate user-facing messages consistent with your brand and regulatory requirements. If status indicates that an institution is unavailable, you may choose to hide it from search results or show a clear, neutral message explaining that the institution cannot be connected at this time. If client_status indicates that an institution is blocked or restricted for your client, provide a concise, neutral explanation without disclosing internal reasons or sensitive details.

Institution Status

The institution.status field represents the global status of the institution across MX.

Client Status

The institution.client_status field represents the institution’s status for your client configuration. This allows MX tooling to apply client-level rules without affecting global institution behavior. When checking if an operation is allowed, client_status is evaluated first, then institution.status. If either field blocks the operation, a 400 Bad Request error is returned with the appropriate message in the error.message field.