> ## Documentation Index > Fetch the complete documentation index at: https://docs.mx.com/llms.txt > Use this file to discover all available pages before exploring further. # List transactions by account per member > Requests to this endpoint return a list of transactions associated with the specified account. ## OpenAPI ````yaml /openapi/platform-api/v20260929.yaml get /users/{user_identifier}/members/{member_identifier}/accounts/{account_identifier}/transactions openapi: 3.0.0 info: contact: name: Platform API v20260929 url: https://www.mx.com/products/platform-api description: > The MX Platform API is a powerful, fully-featured API designed to make aggregating and enhancing financial data easy and reliable. It can seamlessly connect your app or website to tens of thousands of financial institutions. ## Version Header Versions are set in the `Accept-Version` header of API requests. Version numbers correspond with the date associated with that version. The example below uses the version `v20260929`. ``` -H 'Accept: application/json' -H 'Accept-Version: v20260929' ``` --- title: Platform API 2026 version: '2026' servers: - url: https://int-api.mx.com - url: https://api.mx.com security: - basicAuth: [] tags: - name: authorization - name: accounts description: > The Accounts endpoints represent a user's checking, savings, mortgage, 401(k), or other types of accounts held by a financial institution. An account belongs to a `member`, which represents the user's overall relationship with a particular financial institution. A checking account may be just one part of a larger relationship that could also include a car loan and a savings account. Accounts—and the transactions associated with them—are updated every 24 hours, unless the associated `user` is disabled. You can also create manual accounts. Since a manual account has no credentials tied to the member, the account will never aggregate or include data from a data feed. All manual accounts are automatically created under the Manual Institution member. - name: ach return description: > The features documented here are in a beta state, and this documentation is considered draft material subject to frequent change. Using our Platform API, you can securely submit ACH Returns to reduce your ACH return rates and automate your ACH return process. You can query the status and outcomes of your submitted ACH returns to track progress and access resolution details. - name: budgets description: > Use these endpoints to create and manage budgets for your end users. You can create a budget for a specific category or autogenerate a budget for several categories based on existing transactions. Each budget has a `category_guid`, relating to one of the [categories](/api-reference/platform-api/v20260929/reference/categories#default-categories-and-subcategories). - name: categories description: > A `transaction` can have its `category` set to one of MX’s default categories or a custom category for a specific `user`. See [Default Categories and Subcategories](/api-reference/platform-api/v20260929/reference/categories#default-categories-and-subcategories) for a complete list. - name: data exchange description: > Data Exchange provides a secure mechanism for MX clients to share financial data with authorized service providers, external partners, and vendors. Access is controlled through client grants, which define the scope of data an MX client (issuer) makes available to one or more grantees. Each data exchange request requires both standard Platform API authentication and a valid token passed in the `MX-3DX-TOKEN` request header. - name: deprecated - name: goals description: > Use these endpoints to create and manage goals for a `user`. You can also reposition goals to adjust their priority levels. Every goal has a track type and a meta type. The track type (`track_type_name`) is the overall classification of the goal (debt, savings, retirement, or emergency fund) while the meta type (`meta_type_name`) is the specific classification (like college, house, vacation, and so on). - name: insights description: > Use these endpoints to build customizable user experiences in UIs powered by our Financial Insights data. With Financial Insights, your users will receive personalized insights based on their transaction history. Want to learn more about the product? See [Financial Insights](/products/experience/insights). Looking for a guide to use these endpoints? See [Build Your Own Insights UI](/products/experience/insights/integration-guides/insights-api-guide). - name: institutions description: > Institutions represent a financial institution. 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. For more info, see [Institutions Overview](/api-reference/platform-api/v20260929/reference/institutions). - name: investment holdings description: > Investment Data Enhancement lets you connect to an end user's financial institution and retrieve cleansed and enhanced investment data. By combining investment data with retail banking information, you get comprehensive insights into customer financial behaviors, risk tolerance, and investment strategies. You can [read a user's holding](/api-reference/platform-api/v20260929/reference/investment-holdings/read-holding), [list all their holdings](/api-reference/platform-api/v20260929/reference/investment-holdings/list-holdings-by-user), or list their holdings by [account](/api-reference/platform-api/v20260929/reference/investment-holdings/list-holdings-by-account) or [member](/api-reference/platform-api/v20260929/reference/investment-holdings/list-holdings-by-member). You can also [deactivate a user](/api-reference/platform-api/v20260929/reference/investment-holdings/deactivate-user-from-investment-holdings) from the Investment Data Enhancement. This is non-billable. - name: members description: > Members represent the connection between an end user and a financial institution. This institution may represent your institution or another one from which MX is aggregating data. For more info, see [Members Overview](/api-reference/platform-api/v20260929/reference/members). - name: merchants description: > Merchants are representations of a transaction’s origin. For example, if you buy a coffee at Starbucks, the transaction merchant will be `Starbucks`. Use the `merchant_guid` and a `merchant_location_guidon` any `transaction` object to access Merchant endpoints for details like the merchant’s name, logo URL, website, street address, and more. - name: microdeposits description: > Microdeposits is an additional verification method that allows you to verify account details and navigate the process of using microdeposits and the automated clearing house (ACH) system. Make two, small ACH deposits into a consumer's account using the provided account and routing number. You can then require that the end user confirm the exact amount of each deposit to verify that they own the account and meet NACHA’s account verification. For more info, including process flows, setting block lists, and more, see [Microdeposits](/products/connectivity/microdeposits). - name: identity_match description: > Verify user identity by comparing personal information with account owner data from connected financial accounts. - name: monthly cash flow profile - name: notifications description: > You can only use notifications endpoints if you’re using the MX mobile application. All notifications created through the API will be of notification type `API_NOTIFICATION`, channel `PUSH`, and will not be associated to an entity. No other channels are supported. The read and list endpoints can return any notification associated with the `user`, including notifications created by MX for other channels besides `PUSH`. - name: processor token - name: rewards - name: spending plan description: > Use the Spending Plan endpoints to create your own version of our [Spending Plan Widget](/products/experience/pfm/legacy-widget-overviews/spending-plan), which helps end users track their spending throughout the month. To understand key terms and how to best use these endpoints, see [Build Your Own Spending Plan UI](/products/experience/pfm/integration-guides/build-your-own-spending-plan-ui). - name: statements description: > With Statements, you can retrieve a user's monthly account statements in PDF format. This data can be used for solutions like personal financial management or risk analysis. - name: taggings description: > Tags and taggings are two resources in the MX Platform API that, when used together, give end users more control over organizing their transactions. A tag is a custom label that can be applied to a transaction. After you create a tag, use it for tagging. This means you should actually apply the tag to a particular transaction. Together, they're a powerful tool for personalization, customization, and money management. For a guide on creating a tag and then applying it to a specific transaction with a tagging, see [Custom Tags and Taggings](/products/experience/pfm/integration-guides/personalization/). - name: tags description: > Tags and taggings are two resources in the MX Platform API that, when used together, give end users more control over organizing their transactions. A tag is a custom label that can be applied to a transaction. After you create a tag, use it for tagging. This means you should actually apply the tag to a particular transaction. Together, they're a powerful tool for personalization, customization, and money management. For a guide on creating a tag and then applying it to a specific transaction with a tagging, see [Custom Tags and Taggings](/products/experience/pfm/integration-guides/personalization/). - name: transaction rules description: > Transaction Rules allow users to automatically recategorize or rename all similar transactions according to their preferences. This only applies to future transactions. When recategorizing or renaming a transaction, the user will be asked whether they want the new data to apply to the selected transaction or to all future transactions. If they choose to apply it to all future transactions, it will create a transaction rule which will automatically apply the changes going forward. - name: transactions description: > Transactions represent any instance in which money moves into or out of an account. This could be a purchase at a business, a payroll deposit, a transfer from one account to another, an ATM withdrawal, and so on. Transactions are created automatically when a member is successfully aggregated. Each `transaction` belongs to only one `account`. For more info, see [Transactions Overview](/api-reference/platform-api/v20260929/reference/transactions). - name: users description: > Users represent an end user using the Platform API through your web or mobile app. Users are created by MX clients and belong to a specific [client](/products/connectivity/overview/data-architecture#resources) on the platform. - name: verifiable credentials description: > MX provides Verifiable Credential endpoints that comply with web5 standards. For more info, see [Verifiable Credentials Overview](/api-reference/platform-api/v20260929/reference/verifiable-credentials). - name: widgets description: > Use the [Request Widget URL](/api-reference/platform-api/v20260929/reference/widgets/request-widget-url) endpoint to generate a URL that loads one of our widgets. Many request body parameters only work for some widgets. For more info, including widget types, see [Widgets Overview](/api-reference/platform-api/v20260929/reference/widgets). paths: /users/{user_identifier}/members/{member_identifier}/accounts/{account_identifier}/transactions: get: tags: - transactions summary: List transactions by account per member description: >- Requests to this endpoint return a list of transactions associated with the specified account. operationId: listTransactionsByAccountPerMember parameters: - $ref: '#/components/parameters/acceptVersion' - $ref: '#/components/parameters/userIdentifier' - $ref: '#/components/parameters/accountIdentifier' - $ref: '#/components/parameters/memberIdentifier' - $ref: '#/components/parameters/page' - $ref: '#/components/parameters/recordsPerPageMax1000' - $ref: '#/components/parameters/fromDate' - $ref: '#/components/parameters/toDate' - $ref: '#/components/parameters/fromCreatedAt' - $ref: '#/components/parameters/toCreatedAt' - $ref: '#/components/parameters/fromUpdatedAt' - $ref: '#/components/parameters/toUpdatedAt' - $ref: '#/components/parameters/categoryGuidQuery' - $ref: '#/components/parameters/categoryGuidQueryArray' - $ref: '#/components/parameters/topLevelCategoryGuid' - $ref: '#/components/parameters/topLevelCategoryGuidArray' - $ref: '#/components/parameters/includes' responses: '200': content: application/json: schema: $ref: '#/components/schemas/TransactionsIncludesResponseBody' description: OK components: parameters: acceptVersion: name: Accept-Version in: header required: true schema: type: string default: v20260929 example: v20260929 description: MX Platform API version. userIdentifier: description: >- Use either the user `id` you defined or the MX-defined user `guid`. See [Assigning Resource IDs](/products/connectivity/overview/held-data#assigning-resource-ids). in: path required: true name: user_identifier schema: type: string accountIdentifier: description: >- Use either the account `id` you defined or the MX-defined account `guid`. See [Assigning Resource IDs](/products/connectivity/overview/held-data#assigning-resource-ids). in: path required: true name: account_identifier schema: type: string memberIdentifier: description: >- Use either the member `id` you defined or the MX-defined member `guid`. See [Assigning Resource IDs](/products/connectivity/overview/held-data#assigning-resource-ids). name: member_identifier in: path required: true schema: type: string page: description: Results are paginated. Specify current page. example: 1 in: query name: page schema: type: integer recordsPerPageMax1000: description: >- This specifies the number of records to be returned on each page. Defaults to `25`. The valid range is from `10` to `1000`. If the value exceeds `1000`, the default value of `25` will be used instead. example: 10 in: query name: records_per_page schema: type: integer fromDate: description: >- Filter transactions from this date. This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Defaults to 120 days ago if not provided. Maximum date range limit is 6 months. example: '2024-01-01' in: query name: from_date schema: type: string toDate: description: >- Filter transactions to this date (at midnight). This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Defaults to 5 days forward from the day the request is made to capture pending transactions. Maximum date range limit is 6 months. example: '2024-08-28' in: query name: to_date schema: type: string fromCreatedAt: name: from_created_at in: query description: >- Filter transactions from the date the transaction was created. This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Maximum date range limit is 6 months. example: '2024-01-01' schema: type: string toCreatedAt: name: to_created_at description: >- Filter transaction to the date in which the transaction was created. This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Maximum date range limit is 6 months. example: '2024-01-01' in: query schema: type: string fromUpdatedAt: name: from_updated_at description: >- Filter transactions from the date the transaction was updated. This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Maximum date range limit is 6 months. example: '2024-01-01' in: query schema: type: string toUpdatedAt: name: to_updated_at description: >- Filter transactions to the date in which the transaction was updated. This only supports ISO 8601 format without timestamp (YYYY-MM-DD). Maximum date range limit is 6 months. example: '2024-03-31' in: query schema: type: string categoryGuidQuery: name: category_guid description: |- Filter transactions belonging to specified `category_guid`. For example, `?category_guid=CAT-7829f71c-2e8c-afa5-2f55-fa3634b89874`. in: query schema: type: string categoryGuidQueryArray: name: category_guid[] description: >- Filter transactions belonging to any specified `category_guid[]` in url. For example, `?category_guid[]=CAT-7829f71c-2e8c-afa5-2f55-fa3634b89874`. in: query schema: type: array items: type: string topLevelCategoryGuid: name: top_level_category_guid description: >- Filter transactions belonging to specified `top_level_category_guid`. This must be top level category guid, use `category_guid` for subcategory guid. For example, `?top_level_category_guid=CAT-7829f71c-2e8c-afa5-2f55-fa3634b89874`. in: query schema: type: string topLevelCategoryGuidArray: name: top_level_category_guid[] description: >- Filter transactions belonging to any specified `top_level_category_guid[]` in url. This must be top level category guid(s), use `category_guid` for subcategory guid(s). For example, `?top_level_category_guid[]=CAT-7829f71c-2e8c-afa5-2f55-fa3634b89874`. in: query schema: type: array items: type: string includes: description: > Enrich transaction responses with additional metadata. Pass one or more values as an array to selectively include data. Accepted values: `category`, `counterparties`, `merchant`, `repeating_transaction`. Example: `?includes[]=category&includes[]=merchant` Any other value, or a comma-separated string, returns a `400` error. example: - category - merchant in: query name: includes required: false schema: type: array items: type: string enum: - category - counterparties - merchant - repeating_transaction schemas: TransactionsIncludesResponseBody: properties: transactions: items: $ref: '#/components/schemas/TransactionIncludesResponse' type: array pagination: $ref: '#/components/schemas/PaginationResponse' type: object TransactionIncludesResponse: description: >- Extended transaction response. The `category`, `counterparties`, `merchant`, and `repeating_transaction` objects are only present when requested via the `includes[]` query parameter. When included but no data exists, the value is `null`. allOf: - $ref: '#/components/schemas/TransactionSlimResponse' - properties: category: description: >- Only present when `includes[]=category` is specified. Null when no category is associated with the transaction. nullable: true type: object properties: guid: description: The unique identifier for the category. Defined by MX. example: CAT-b6d61a19-30a7-e852-2703-bdfb4072289e type: string name: description: The name of the category. example: Paycheck type: string top_level_category: description: The parent category assigned to this transaction's category. example: Income nullable: true type: string self: description: The API URI path to access the category details. example: /categories/CAT-b6d61a19-30a7-e852-2703-bdfb4072289e nullable: true type: string counterparties: description: >- Only present when `includes[]=counterparties` is specified. Null when no counterparties are associated with the transaction. type: array nullable: true items: type: object description: >- A party involved in the transaction, for example a payment processor and the underlying merchant. properties: confidence_level: description: >- The confidence level of the counterparty match, represented as "Very High" or "Low". example: Very High nullable: true type: string guid: description: The unique identifier for the counterparty. Defined by MX. example: MCH-0c25f895-393c-42a4-9c18-95a0b26d4d84 nullable: true type: string logo_url: description: The URL for a 100px X 100px logo for the counterparty. example: >- https://content.mx.com/logos/merchants/MCH-0c25f895-393c-42a4-9c18-95a0b26d4d84.png nullable: true type: string name: description: The name of the counterparty. example: MX type: string website_url: description: The URL for the counterparty's website. example: https://www.example.com nullable: true type: string merchant: description: >- Only present when `includes[]=merchant` is specified. Null when no merchant is associated with the transaction. type: object nullable: true properties: confidence_level: description: >- The confidence level of the merchant assignment for the transaction, represented as "Very High" or "Low". example: Very High nullable: true type: string guid: description: The unique identifier for the merchant. Defined by MX. example: MCH-0c25f895-393c-42a4-9c18-95a0b26d4d84 type: string logo_url: description: The URL for a 100px X 100px logo for the merchant. type: string example: >- https://content.mx.com/logos/merchants/MCH-0c25f895-393c-42a4-9c18-95a0b26d4d84.png name: description: The name of the merchant. example: MX type: string self: description: The API URI path to access the merchant details. example: /merchants/MCH-0c25f895-393c-42a4-9c18-95a0b26d4d84 nullable: true type: string website_url: type: string description: URL to the merchant's website. example: https://www.example.com repeating_transaction: description: >- Only present when `includes[]=repeating_transaction` is specified. Null when no repeating transaction is associated with the transaction. nullable: true type: object properties: frequency: description: >- The frequency at which the transaction is expected to repeat. See [Supported Recurrence Types](/api-reference/platform-api/v20260929/reference/transactions#supported-recurrence-types). type: string example: EVERY_MONTH enum: - EVERY_WEEK - EVERY_OTHER_WEEK - TWICE_A_MONTH - EVERY_MONTH - EVERY_OTHER_MONTH - EVERY_QUARTER - EVERY_OTHER_QUARTER - EVERY_YEAR - UNKNOWN guid: description: >- The unique identifier for the repeating transaction. Defined by MX. type: string example: RPT-065b8b1d-826a-45ce-8487-60ca1510e72a self: description: >- The API URI path to access the repeating transaction details. example: >- /users/USR-11141024-90b3-1bce-cac9-c06ced52ab4c/repeating_transactions/RPT-065b8b1d-826a-45ce-8487-60ca1510e72a nullable: true type: string type: description: The type of the repeating transaction. type: string enum: - BILL - SUBSCRIPTION - INCOME - UNKNOWN type: object PaginationResponse: properties: current_page: description: The page delivered by the current response. example: 1 type: integer per_page: description: The number of records delivered with each page. example: 25 type: integer total_entries: description: The total number of records available. example: 1 type: integer total_pages: description: The total number of pages available. example: 1 type: integer type: object TransactionSlimResponse: allOf: - $ref: '#/components/schemas/TransactionBaseResponse' - type: object properties: account: $ref: '#/components/schemas/AccountBaseResponse' member: $ref: '#/components/schemas/MemberBaseResponse' user: $ref: '#/components/schemas/UserBaseResponse' mx_record: $ref: '#/components/schemas/MxRecordBaseResponse' TransactionBaseResponse: properties: amount: description: The monetary amount of the `transaction`. example: 61.11 nullable: false type: number currency_code: description: The three-character ISO 4217 currency code, for example, `USD`. example: USD nullable: true type: string date: description: >- The date on which the transaction took place. This is the field used when searching for transactions by date and is generally the same as `transacted_at`, but uses `posted_at` as a fallback. example: '2024-12-20' nullable: true type: string description: description: A human-readable description of the transaction. example: MX Technologies Payroll nullable: true type: string guid: description: The unique identifier for the transaction. Defined by MX. example: TRN-429ad9fe-a1d2-4559-8590-885b2603f0e1 nullable: true type: string id: description: The unique partner-defined identifier for the transaction. example: 1734681600000-178fa8095c154a55b9172f977b4c5f9a-0 nullable: true type: string self: description: The API URI path to access the transaction details. example: >- /users/USR-11141024-90b3-1bce-cac9-c06ced52ab4c/transactions/TRN-429ad9fe-a1d2-4559-8590-885b2603f0e1 nullable: false type: string status: description: > The status of the transaction. All transaction data on our systems represent what we get through our data feed which depends what institutions make available for aggregation. Many institutions do not provide data for pending transactions; transactions from those accounts always have a status of `POSTED`. When we do receive data for pending transactions, a single transaction may be updated from `PENDING` to `POSTED` and keep the same `guid`. This is done through various matching methods performed automatically by MX. If a single transaction can't be updated, the `PENDING` transaction will often be deleted and replaced with a new `POSTED` transaction (with a new `guid`) when it is sent to us; this is the most common scenario when pending data is available. In unusual circumstances, there may be separate `PENDING` and `POSTED` transactions on MX systems for up to 14 days. All `PENDING` transactions are deleted after 14 days as a failsafe. example: POSTED type: string nullable: true enum: - POSTED - PENDING type: description: The type of transaction. example: CREDIT nullable: true type: string enum: - CREDIT - DEBIT AccountBaseResponse: description: >- The base fields for an account. Returned as the `account` companion on related resources such as transactions, statements, and rewards, and as the foundation of full account responses. properties: account_number_display: description: >- The account number associated with the account. This will typically be a masked or partial account number. example: '3331261' type: string nullable: true subtype: description: >- The account's subtype, for example, `PLAN_401_K`, `MONEY_MARKET`, or `HOME_EQUITY`. Each subtype belongs to an account `type`. For a full list of account subtypes and types, see [Accounts](/api-reference/platform-api/v20260929/reference/accounts#account-types). example: CHECKING nullable: true type: string type: description: >- The type of account. Some account types may include subtypes. For a full list of account types and subtypes, see [Account Types](/api-reference/platform-api/v20260929/reference/accounts#account-types). example: CHECKING nullable: true type: string enum: - ANY - CASH - CHECKING - CHECKING_LINE_OF_CREDIT - CREDIT_CARD - LOAN - LINE_OF_CREDIT - SAVINGS - INVESTMENT - MORTGAGE - INSURANCE - PREPAID - PROPERTY guid: description: Unique identifier for the account. Defined by MX. example: ACT-06d7f44b-caae-0f6e-1384-01f52e75dcb1 nullable: true type: string id: description: The unique partner-defined identifier for the account. example: '1040434698' nullable: true type: string name: description: The human-readable name for the `account`. example: Test account 2 type: string nickname: description: An alternate name for the `account`. example: Swiss Account type: string self: description: The API URI path for the account. example: >- /users/USR-11141024-90b3-1bce-cac9-c06ced52ab4c/accounts/ACT-06d7f44b-caae-0f6e-1384-01f52e75dcb1 type: string type: object MemberBaseResponse: description: >- The base fields for a member, which is a user's connection to an institution. Returned as the `member` companion on related resources such as accounts and transactions, and as the foundation of full member responses. properties: guid: description: The unique identifier for the member. Defined by MX. example: MBR-7c6f361b-e582-15b6-60c0-358f12466b4b nullable: false type: string id: description: The unique partner-defined identifier for the member. example: unique_id nullable: true type: string metadata: description: Additional information you can store about the member. example: some metadata nullable: true type: string name: description: The name of the member. example: MX Bank nullable: true type: string self: description: The API URI path for the member. example: >- /users/USR-11141024-90b3-1bce-cac9-c06ced52ab4c/members/MBR-7c6f361b-e582-15b6-60c0-358f12466b4b nullable: false type: string UserBaseResponse: description: >- The base fields for a user. Returned as the `user` companion on related resources such as members, accounts, and transactions, and as the foundation of full user responses. properties: guid: description: The unique identifier for the user. Defined by MX. example: USR-11141024-90b3-1bce-cac9-c06ced52ab4c nullable: false type: string id: description: The unique partner-defined identifier for the user. example: unique_id nullable: true type: string metadata: description: Additional information you can store about the user. example: some metadata nullable: true type: string self: description: The API URI path for the `user`. example: /users/USR-11141024-90b3-1bce-cac9-c06ced52ab4c nullable: false type: string MxRecordBaseResponse: description: >- Timestamps for when MX created and last updated the record. Returned as the `mx_record` companion on all resources persisted by MX. These describe the MX record, not the underlying resource at the institution. properties: created_at: description: >- The date and time the resource was created in MX Platform, represented in ISO 8601 format with a timestamp. example: '2025-05-10T18:08:00Z' nullable: true type: string updated_at: description: > The date and time the resource was last updated in MX Platform, represented in ISO 8601 format with a timestamp. For categories, this field will always be `null` when `is_default` is `true`. example: '2026-02-12T22:48:21Z' nullable: true type: string securitySchemes: basicAuth: scheme: basic type: http description: > To authenticate with the Platform API, include your Base64-encoded `client_id` and `api_key` in the Authorization header of every request: ``` -H 'Authorization: Basic BASE_64_ENCODING_OF{client_id:api_key}' ``` ````