---
title: "Screen a single transaction by hash"
method: POST
path: "/v1/tx-enrich"
tags: ["Screening"]
---

# Screen a single transaction by hash

`POST /v1/tx-enrich`

## Request

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

Economic summary of one transaction plus a label and risk reading for every participant, and a direction-aware verdict.

Pass `focus_address` — the wallet you are actually screening, e.g. your own deposit address — to scope the verdict to its direct counterparties and the direction the money moved relative to it. Without it the verdict is about the transaction as a whole.

Some chains need `block_number` alongside the hash to resolve it at all; the response says so with a 422 naming the reason. Locate the block with /v1/transactions if you do not have it.

## Request body

- object
  - `tx_hash` string, required: EVM hashes are 0x-prefixed; bitcoin txids are bare hex. Both accepted.
  - `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.
  - `block_number` integer: Required on chains that cannot resolve a bare hash — see the 422.
  - `focus_address` string: The wallet being screened, if any. 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.
  - `include` string[]: Default ['economics','risk'].

## Response `200`

The enriched transaction.

- object
  - `tx_hash` string
  - `chain` string
  - `found` boolean
  - `economics` object
  - `risk` object
  - `participants` object[]: Each carries aml_score, risk_level, category, label, sanctioned and its role in the transaction.

## Other responses

- `400`: Malformed request.
- `404`: Transaction not found in the indexed data.
- `422`: block_number is required for this chain.
- `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)