Graph

Who an address transacted with, with amounts per token

Three modes, selected by which field you send. They do not combine.

  1. filter — you already have candidate addresses and want to know whether this wallet dealt with them, and for how much. Ones with no recorded interaction are dropped from the answer.
  2. category — 'did this wallet touch any exchange / mixer / casino'.
  3. kinds — ENUMERATE the counterparties and classify each as a person, a venue, a hub, a deposit address, a contract or a mint/burn pseudo-address. This is the mode for 'which ordinary people funded this address'. An unlabelled counterparty is NOT thereby a person — that is what the degree probe in this mode is for.

Self-loops are kept here, unlike in /v2/enrich.

post/v1/counterparties

Request

  • Base URL: https://intelapi.publicaml.org
  • URL: https://intelapi.publicaml.org/v1/counterparties
  • Auth: one of:
    • API key in header X-API-Key
    • none

Request body

wallet_addressstring required

The wallet whose counterparties to look at.

The address to look up, in its normal display form.

  • bitcoin — base58 (1…, 3…) or bech32/bech32m (bc1…, bc1p…). Case is SIGNIFICANT for base58; do not lowercase it. A 64-character lowercase TRANSACTION HASH is also accepted here: on bitcoin the graph is bipartite (address → transaction → address), so a transaction is a node with its own neighbours and its own findings. CoinJoin is classified on the transaction, not on the participants, and this is how you read it.
  • ethereum, bsc — 0x + 40 hex characters, any case.
  • tron — base58 (T…, 34 characters); the 0x 20-byte form is accepted too and is what the API stores and echoes.
chain'bitcoin' | 'ethereum' | 'bsc' | 'tron' required

Which blockchain the address belongs to. Send one of the four values in the enum. The short forms used by the older clients (ETH, BTC, TRX, BNB) and any capitalisation are still accepted, but responses always echo the canonical spelling.

Getting this wrong is the single commonest integration bug: the same 0x-prefixed address exists on ethereum, bsc and tron and means a different wallet on each, so the chain is part of the identity, never a hint. If it does not match the address format the call fails with invalid_address_format, which names the chain the address does look like.

filterstring[]

Mode 1: candidate counterparty addresses to check.

categorystring

Mode 2: entity type to match — cex, mixer, gambling, bridge, …

kindsstring[]

Mode 3: which classes of counterparty to return. Sending this field is what selects the mode; it is a 400 alongside filter or category.

direction'in' | 'out' | 'both'

kinds mode. 'in' (the default there) = who paid this address.

rank_by'value' | 'tx_count'

'value' weighs token units with NO price attached, so a memecoin sender can outrank an ETH sender. Use 'tx_count' to avoid that.

limitinteger
offsetinteger
budget_secnumber

kinds mode: wall-clock budget for the degree probe.

includestring[]

['risk'] adds aml_score, risk_level and sanctioned to each row.

Response

Counterparties with per-token amounts.

wallet_addressstring
chainstring
summaryobject

kinds mode: count per kind.

value_splitobject

kinds mode: how the value divides across kinds, tokens at face value.

coverageobject

What the scan actually managed to read.

partialboolean

true = a cap or budget cut the answer, so the list is a floor, not the whole set.

request_idstring
processing_time_msinteger

Changes

No recorded changes to this operation across all 1 revision of this API.