ChainwatchCrypto—blockchain intelligence and investigative operationsAll systems operational
API Platform

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.

Scoped keysSigned webhooksIdempotent writes
Request
# 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.

Structured blockchain events passing through a scoped and verified API gateway.
Design rules

Four commitments the API is built to.

RuleWhat it means for your integration
Analytical honestyEvery risk response carries its model version, hop limit and an explicit disclaimer field. A consumer cannot accidentally strip the caveat.
Idempotent writesEvery write accepts an idempotency key. A retried request cannot create a second case, a second monitoring rule or a second alert.
Explicit stalenessWhere 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 errorsErrors return a machine-readable code and a human-readable message. Codes do not change meaning between versions.
These are example architecture patterns

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.

Endpoints

The categories, at a glance.

MethodPathPurpose
GET/v1/wallets/{address}Wallet profile: activity, counterparties, exposure and current risk.
GET/v1/wallets/{address}/transfersPaginated transfers for an address, filterable by asset and direction.
GET/v1/transactions/{hash}Normalised transaction detail across supported networks.
POST/v1/risk/checkScore an address or transaction against your active policy.
POST/v1/monitoring/walletsAdd an address to monitoring with rules and thresholds.
GET/v1/monitoring/walletsList monitored addresses and their current rule sets.
DELETE/v1/monitoring/wallets/{id}Stop monitoring an address.
GET/v1/alertsAlerts raised for your organisation, filterable by rule, severity and state.
GET/v1/cases/{id}Case state, stage, assigned investigator and available reports.
POST/v1/casesCreate a case from an intake payload.
GET/v1/entities/{id}Entity profile with attributions, sources and confidence levels.
POST/v1/screening/sanctionsScreen an address or identifier against ingested list versions.
GET/v1/reports/{id}Report metadata, version and download authorisation.

Get API access.

API access is provisioned under a platform agreement, with scopes and rate limits set to your integration.