---
title: "Raw transfers between two specific addresses"
method: POST
path: "/v1/transactions"
tags: ["Graph"]
---

# Raw transfers between two specific addresses

`POST /v1/transactions`

## Request

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

Every recorded transfer from one address to another.

Chain-aware: on EVM chains these are the direct edges between the two addresses. On bitcoin, whose graph has no direct address-to-address edge, it returns the FULL edge set of the transactions where both addresses appear — co-inputs and change outputs included, because those are what attribution turns on.

## Request body

- object
  - `from` string, required: Sending address. 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.
  - `to` string, required: Receiving address. 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.
  - `limit` integer
  - `offset` integer: Skip-based paging. Kept for compatibility; prefer `cursor` — a deep offset re-reads everything it skips.
  - `cursor` string: The `next_cursor` of the previous page. '<block>:<tx_hash>' on bitcoin, '<block>:<log_index>:<internal_index>' elsewhere. Refused together with `offset`.
  - `token` string: Restrict to one token contract. Rejected on bitcoin.

## Response `200`

The transfers between the two addresses.

- object
  - `count` integer
  - `transactions` object[]
  - `request_id` string

## Other responses

- `400`: Malformed request.
- `429`: Rate limited: anonymous callers, and keys issued with a quota of their own. Authenticate to remove the limit.
- `500`: Server error.

---

[API](https://skmtc.dev/publicaml/apis/publicaml-intelligence-api.md) · [All operations](https://skmtc.dev/publicaml/apis/publicaml-intelligence-api/llms.txt) · [OpenAPI document](https://skmtc.dev/publicaml/apis/publicaml-intelligence-api/revisions/7c0c6315088c?raw)