v51

latestOpenAPI 3.0.0raw.githubusercontent.com2026-07-313352,3122.9 MB
plaid

Get transaction data

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 or mortgage; coverage may be limited). For transaction history from investment 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.

post/transactions/get

Request body

client_idstring

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.

access_tokenstring required

The access token associated with the Item for which data is being requested.

secretstring

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.

start_datestring date required

The earliest date for which data should be returned. Dates should be formatted as YYYY-MM-DD.

end_datestring date required

The latest date for which data should be returned. Dates should be formatted as YYYY-MM-DD.

Response

OK

total_transactionsinteger required

The total number of transactions available within the date range specified. If total_transactions is larger than the size of the transactions array, more transactions are available and can be fetched via manipulating the offset parameter.

request_idstring required

A unique identifier for the request, which can be used for troubleshooting. This identifier, like all Plaid identifiers, is case sensitive.