Transfers API Quickstart

Quickstart guide for getting transfers and transaction history for contracts and addresses on Ethereum and Polygon. The Transfers API allows you to easily fetch historical transactions for any address without having to scan the entire chain and index everything for each of your users.

To use the Transfers API you'll need to create a free Alchemy account first!

What are Transfers?

Transfers are a representation of value being exchanged between two accounts. Often times users wish to see the historical transactions associated with a specific account or address. This is currently an extremely challenging and inefficient task, requiring users to scan the entire blockchain and index everything to search for transactions associated with the desired address. However, with the Transfers API users can query all types of historical transactions for a given address in a single request.

What's an Example Use Case for Transfers?

An example use case for the requesting transfer events would be integrating historical transaction data into your dApp. For instructions on how to do this check out this tutorial on Integrating Historical Transaction Data into your dApp.

What networks does the Transfers API support?

The Transfers API is currently supported on Ethereum and Polygon. For a feature matrix for types of transfers supported on each network check out Types of Transfers.

Types of Transfers

There are five main types of transfers that are captured when using this API. See below for the types of transfers supported on each network.

Type of TransferEthereum Mainnet, GoerliPolygon Mainnet, MumbaiEthereum Kovan, Rinkeby, Ropsten

1. External Eth Transfers

These are top level ethereum transactions that occur with a from address being an external (user created) address. External addresses have private keys and are accessed by users.

2. ERC20 Transfers

Event logs for ERC20 transfers.

3. ERC721 Transfers

Event logs for ERC721 transfers.

4. ERC1155 Transfers

These are event logs for ERC1155 transfers.

5. Internal Eth Transfers

These are transfers that occur where the fromAddress is an internal (smart contract) address. (ex: a smart contract calling another smart contract or smart contract calling another external address). For a full deep dive into internal transfers check out this article on What are Internal Transactions?.


Note on Internal Transfers

For efficiency, we do not return internal transfers with 0 value as they don't provide useful information without digging deeper into the internal transaction itself. If you are interested in these type of events see our Trace API.

Additionally, we do not include any internal transfers with call type delegatecall because although they have a value associated with them they do not actually transfer that value (see Appendix H of the Ethereum Yellow Paper if you're curious).

We also do not include miner rewards as an internal transfer.

6. Special NFT Transfers

The special NFT endpoint allows users to query for NFTs that don't follow any ERC standards. For instance, 2 included NFTs are CryptoPunks and CryptoKitties which both predate NFT standards.


There are two cases in which pagination will be required:

  1. If you have a specific number of responses that you want to receive in a given payload
  2. If you receive a response with more than 1000 results.

In the first case, you should use the maxCount parameter in your request to specify the number of responses you wish to receive. If there are more results than specified in maxCount, you will receive a value for pageKey in your result which you should use to fetch the next response load by putting the returned pageKey value in the pageKey parameter of your next request. Continue to do so until a pageKey is no longer returned (meaning you've fetched all the results).

In the second case, you will also receive a value for pageKey in the response, which you should use to fetch the next 1000 (or however many is left) by putting the returned pageKey value in the pageKey parameter of your next request.



Each page key has a TTL (Time to Live) of 10 minutes so if you receive a response with a pageKey value you must send the next request (with the pageKey) within the 10 minute window, otherwise you will have to restart the entire request cycle.

How to get timestamps for a transaction

A transaction object will have a block number associated with it, the block number is Ethereum's measure of time, however, if you want a standard timestamp you can easily get that by specifying withMetadata=true in your alchemy_getAssetTransfers request, or make a second call to eth_getBlockByNumber, passing in the blockNum field from the alchemy_getAssetTransfers response payload.


Understanding Block Timestamps

Surprisingly, a block's timestamp is actually the time that the previous block was mined not the block that the timestamp is contained within. So for Ethereum Mainnet, blocks tend to actually be mined around 14 seconds after their timestamps.

How are transactions ordered?

By default the Transfers API returns transactions in ascending order so from oldest --> newest transactions. However if you wish to change the order to be from newest --> oldest transactions you can do so by specifying the order parameter to desc.