POST /transactions/get

Note: All new implementations are encouraged to use /transactions/sync rather than /transactions/get. /transactions/sync provides the same functionality as /transactions/get and improves developer ease-of-use for handling transactions updates.

The /transactions/get endpoint allows developers to receive user-authorized transaction data for credit, depository, and some loan-type accounts (only those with account subtype student; coverage may be limited). For transaction history from investments accounts, use the Investments endpoint instead. Transaction data is standardized across financial institutions, and in many cases transactions are linked to a clean name, entity type, location, and category. Similarly, account data is standardized and returned with a clean name, number, balance, and other meta information where available.

Transactions are returned in reverse-chronological order, and the sequence of transaction ordering is stable and will not shift. Transactions are not immutable and can also be removed altogether by the institution; a removed transaction will no longer appear in /transactions/get. For more details, see Pending and posted transactions.

Due to the potentially large number of transactions associated with an Item, results are paginated. Manipulate the count and offset parameters in conjunction with the total_transactions response body field to fetch all available transactions.

Data returned by /transactions/get will be the data available for the Item as of the most recent successful check for new transactions. Plaid typically checks for new data multiple times a day, but these checks may occur less frequently, such as once a day, depending on the institution. To find out when the Item was last updated, use the Item Debugger or call /item/get; the item.status.transactions.last_successful_update field will show the timestamp of the most recent successful update. To force Plaid to check for new transactions, you can use the /transactions/refresh endpoint.

Note that data may not be immediately available to /transactions/get. Plaid will begin to prepare transactions data upon Item link, if Link was initialized with transactions, or upon the first call to /transactions/get, if it wasn't. To be alerted when transaction data is ready to be fetched, listen for the INITIAL_UPDATE and HISTORICAL_UPDATE webhooks. If no transaction history is ready when /transactions/get is called, it will return a PRODUCT_NOT_READY error.

Servers

https://production.plaid.com
https://sandbox.plaid.com

Request headers

Name	Type	Required	Description
`Content-Type`	String	Yes	The media type of the request body. Default value: "application/json"

Request body fields

Name	Type	Required	Description
`start_date`	String	Yes	The earliest date for which data should be returned. Dates should be formatted as YYYY-MM-DD.
`client_id`	String	No	Your Plaid API `client_id`. The `client_id` is required and may be provided either in the `PLAID-CLIENT-ID` header or as part of a request body.
`options`	Object	No	An optional object to be used with the request. If specified, `options` must not be `null`.
`options.include_personal_finance_category`	Boolean	No	Personal finance categories are now returned by default. Default value: false
`options.days_requested`	Integer	No	This field only applies to calls for Items where the Transactions product has not already been initialized (i.e. by specifying `transactions` in the `products`, `optional_products`, or `required_if_consented_products` array when calling `/link/token/create` or by making a previous call to `/transactions/sync` or `/transactions/get`). In those cases, the field controls the maximum number of days of transaction history that Plaid will request from the financial institution. The more transaction history is requested, the longer the historical update poll will take. If no value is specified, 90 days of history will be requested by default. If a value under 30 is provided, a minimum of 30 days of history will be requested. If you are initializing your Items with transactions during the `/link/token/create` call (e.g. by including `transactions` in the `/link/token/create` `products` array), you must use the `transactions.days_requested` field in the `/link/token/create` request instead of in the `/transactions/get` request. If the Item has already been initialized with the Transactions product, this field will have no effect. The maximum amount of transaction history to request on an Item cannot be updated if Transactions has already been added to the Item. To request older transaction history on an Item where Transactions has already been added, you must delete the Item via `/item/remove` and send the user through Link to create a new Item. Customers using Recurring Transactions should request at least 180 days of history for optimal results. Default value: 90
`options.count`	Integer	No	The number of transactions to fetch. Default value: 100
`options.include_original_description`	Boolean	No	Include the raw unparsed transaction description from the financial institution. Default value: false
`options.include_logo_and_counterparty_beta`	Boolean	No	Counterparties and extra merchant fields are now returned by default. Default value: false
`options.account_ids[]`	Array	No	A list of `account_ids` to retrieve for the Item Note: An error will be returned if a provided `account_id` is not associated with the Item.
`options.include_personal_finance_category_beta`	Boolean	No	Personal finance categories are now returned by default. Default value: false
`options.offset`	Integer	No	The number of transactions to skip. The default value is 0. Default value: 0
`end_date`	String	Yes	The latest date for which data should be returned. Dates should be formatted as YYYY-MM-DD.
`access_token`	String	Yes	The access token associated with the Item data is being requested for.
`secret`	String	No	Your Plaid API `secret`. The `secret` is required and may be provided either in the `PLAID-SECRET` header or as part of a request body.

How to start integrating

Add HTTP Task to your workflow definition.
Search for the API you want to integrate with and click on the name.
- This loads the API reference documentation and prepares the Http request settings.
Click Test request to test run your request to the API and see the API's response.