Address transfer monitoring — Introduction

Product overview

Introduction

Address transfer monitoring is designed for business systems that need to track on-chain transfer activity for wallet addresses. The service continuously receives and parses multi-chain transaction data, persists normalized transfer records, and exposes the results through HTTP queries and WebSocket pushes.

The goal is to let integrators monitor selected addresses without operating their own nodes or building a full transaction parsing pipeline. Integrators only need to maintain their monitored address list and keep their delivery connection available.

---

Core capabilities

Capability	Description
Multi-chain transaction monitoring	Unified ingestion for EVM-compatible chains, Solana, Tron, Bitcoin, and other supported networks.
Real-time push	Pushes on-chain transactions to subscribed clients through WebSocket.
Historical query	Queries historical transactions for addresses through HTTP APIs.
Address subscription management	Adds and removes monitored addresses dynamically, with business isolation based on the public API key.
Webhook notification	Delivers transaction data to an HTTP callback configured by the service side.

---

Supported chains

EVM-compatible chains

Chain	chain_type	Mainnet chain_id
Ethereum	ethereum	1
BNB Smart Chain	bsc	56
Polygon	polygon	137
Arbitrum One	arbitrum	42161
Optimism	optimism	10
Base	base	8453

Non-EVM chains

Chain	chain_type	Mainnet chain_id
Solana	solana	1
Tron	tron	1
Bitcoin	bitcoin	1

chain_type is case-insensitive in requests. The service normalizes it to lowercase.

---

Core concepts

Chain identity: chain_type and chain_id

Each chain is identified by two fields:

• chain_type: the chain type name, such as ethereum, solana, or tron.
• chain_id: the chain ID used to distinguish mainnets and testnets, such as 1 for Ethereum Mainnet and 11155111 for Sepolia.

These two fields are used by every API that involves chain-specific data.

Public authentication: X-API-Key

The public APIs currently exposed by the service use the X-API-Key request header for API authentication and billing identification. Address management, transaction query, and WebSocket connections should all carry this header.

X-API-Key: your-api-key

Standard response format

Most APIs follow this JSON response structure:

{
  "code": 0,
  "message": "ok",
  "data": {}
}

Field	Type	Description
code	integer	Business status code. 0 means success.
message	string	Response message. Successful responses usually use ok.
data	any	Business data. Failed responses usually return null.

Some legacy APIs use msg instead of message. Follow the specific API documentation for each endpoint.

Error response format

Failed requests return a structure similar to:

{
  "code": 400,
  "msg": "Invalid request",
  "data": null
}

Common HTTP status codes:

Status	Meaning
400	Request parameter validation failed.
401	Authentication failed for the stream secret.
403	No permission because the API key is invalid.
504	Request timed out after 15 seconds.
500	Internal service error.

---

Authentication

All public APIs use the X-API-Key request header. The key is used for API authentication, caller identification, and billing statistics.

Public API key (X-API-Key)

All public API requests should carry:

X-API-Key: your-api-key