中文 (简体) | 中文 (繁體) | 日本語 | 한국어 | Türkçe | Русский | Italiano | Español

Note: This documentation is deprecated and no longer maintained. Please refer to the updated API documentation for the most current information.

Disclaimers

We cannot make a backwards compatibility guarantee on our endpoints. We are only releasing this documentation due to a large amount of demand for direct API access, and this is just a pilot for releasing our API more fully. That said, we will try our best to be accommodating for anyone using our API, so if you significantly integrate our API into your infrastructure please let us know so we can give you a warning about potential breaking changes.

Authentication

All you need to do to authenticate with Arkham’s API is provide a valid API key in the header of your request. The header key is API-Key. Currently there is no way to generate an API key through our UI or API—we give them out manually. If you would like an API key let us know.

Endpoints

Our root URL is https://api.arkhamintelligence.com.

Requests to our API are rate limited to 5 requests per second with a small additional burst allowance if you go over that. We might lower this in the future, I would aim to be under it by a good amount.

If you are consistently hitting the default rate limit we have set for our API you can apply for a rate limit increase here.

The endpoints documented here are not exhaustive—I will add to them as more are requested.

GET /transfers

Parameters

All as query parameters

• base
  • Type: string[]
  • Required
  • Entities/addresses you want to see transactions either from or to
  • Must be an address or entity id (you can find entity ids by looking at the url of an /explorer/entity page). We unfortunately do not expose a list of all entity_ids we have, though our search bar is pretty good if you know the name. But usually it’s just a slugified version of the name: Alameda Research -> alameda-research.
  • To include multiple, just comma separate them. You can even include a mix of addresses and entities. For example:
    • ftx
    • ftx,binance
    • 0x123...,0x456...,alameda-research
  • If you create an entity you can also pass its ID here.
• chains
  • Type: string[]
  • Optional, if empty it will default to all chains
  • Supported chains: ethereum, bsc, polygon, arbitrum_one, avalanche, optimism, bitcoin, tron, base, flare.
• flow
  • Type: "in" | "out" | "all"
  • Default: all
  • Flow is with respect to base so if you choose e.g. out you will only see transactions coming from base regardless of your other filters.
• from
  • Type: string[]
  • Filter for only transactions from certain entities/addresses. If you include multiple you will get transactions from any of the entities/addresses specified to any of the addresses/entities specified in base
  • In addition to entity ID’s and addresses (same as in base) you can also include entity types and exchange IDs for deposits. For example:
    • type:cex will give you all transactions from centralized exchanges
    • deposit:binance will give you all transactions to binance deposit addresses. You can pass an ID there for any entity that uses a deposit address pattern, not just exchanges (custody platforms, OTC desks, gambling sites, etc). If we’ve identified a hot wallet for an entity, we auto-label deposits for it and you can query for them.
    • deposit:all will give you transactions to any deposit address.
  • If you prefix an option with ! it will negate that option. For instance, type:cex,!binance will filter for “to centralized exchanges but not to binance”. This option is available for types, entities, and addresses, but not deposit entity IDs.
  • All positive filters are internally OR’d together, and all negative filters are internally AND’d against each other and against the positive filters. Thus, type:cex,deposit:all,!binance,!huobi will filter for transactions to centralized exchanges or any deposit addresses but not to huobi or binance.