The same intelligence, inside your own systems.
A REST API over the platform graph: wallet profiles, transaction detail, risk checks, monitoring rules, alerts, cases, entities and screening — with scoped keys, rate limits and signed webhooks.
# Every request is authenticated with a scoped key. curl "https://api.chainwatchcrypto.com/v1/risk/check" \ -H "Authorization: Bearer cw_live_..." \ -H "Content-Type: application/json" \ -d '{"address":"0x4f2c…9ac2","network":"ethereum"}' # Response { "address": "0x4f2c…9ac2", "network": "ethereum", "risk": { "score": 78, "level": "elevated", "model_version": "2026.02", "hop_limit": 5, "signals": [ { "key": "transaction_exposure", "value": 24 }, { "key": "known_risk_exposure", "value": 18 } ] }, "disclaimer": "Analytical indicator; not a determination of unlawful conduct." }
What does the ChainwatchCrypto API do?
The ChainwatchCrypto REST API exposes wallet intelligence, transaction detail, risk checks, monitoring, alerts, cases, entities and screening to your own systems. Authentication uses scoped keys and events arrive by signed webhooks. Supported networks vary by endpoint, and an unsupported combination returns an explicit error rather than a partial result.

Where to start.
API reference
Endpoints, parameters, responses and error shapes.
Learn moreAuthentication
Keys, scopes, environments, rotation and IP restrictions.
Learn moreWebhooks
Event types, signing, retries and idempotency.
Learn moreRate limits
Per-key limits, burst behaviour and the headers that report them.
Learn moreExamples
Request and response examples for the common integrations.
Learn moreStatus
Component status for the API and webhook delivery.
Learn moreFour commitments the API is built to.
| Rule | What it means for your integration |
|---|---|
| Analytical honesty | Every risk response carries its model version, hop limit and an explicit disclaimer field. A consumer cannot accidentally strip the caveat. |
| Idempotent writes | Every write accepts an idempotency key. A retried request cannot create a second case, a second monitoring rule or a second alert. |
| Explicit staleness | Where a blockchain provider is degraded, the response carries a stale flag and the timestamp of the last good read rather than silently returning old data. |
| Stable errors | Errors return a machine-readable code and a human-readable message. Codes do not change meaning between versions. |
The endpoint shapes on these pages describe the platform's API architecture. They are not a commitment to a specific endpoint list; confirm the current contract during integration scoping.
The categories, at a glance.
| Method | Path | Purpose |
|---|---|---|
| GET | /v1/wallets/{address} | Wallet profile: activity, counterparties, exposure and current risk. |
| GET | /v1/wallets/{address}/transfers | Paginated transfers for an address, filterable by asset and direction. |
| GET | /v1/transactions/{hash} | Normalised transaction detail across supported networks. |
| POST | /v1/risk/check | Score an address or transaction against your active policy. |
| POST | /v1/monitoring/wallets | Add an address to monitoring with rules and thresholds. |
| GET | /v1/monitoring/wallets | List monitored addresses and their current rule sets. |
| DELETE | /v1/monitoring/wallets/{id} | Stop monitoring an address. |
| GET | /v1/alerts | Alerts raised for your organisation, filterable by rule, severity and state. |
| GET | /v1/cases/{id} | Case state, stage, assigned investigator and available reports. |
| POST | /v1/cases | Create a case from an intake payload. |
| GET | /v1/entities/{id} | Entity profile with attributions, sources and confidence levels. |
| POST | /v1/screening/sanctions | Screen an address or identifier against ingested list versions. |
| GET | /v1/reports/{id} | Report metadata, version and download authorisation. |
