GET /v2/check-address/{check_id}/result

Fetch the check-address result (charged once on success)

curl --request GET \
  --url https://api.aegis-kyt.com/v2/check-address/{check_id}/result \
  --header 'Authorization: Bearer <token>'

import requests

url = "https://api.aegis-kyt.com/v2/check-address/{check_id}/result"

headers = {"Authorization": "Bearer <token>"}

response = requests.get(url, headers=headers)

print(response.text)

const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};

fetch('https://api.aegis-kyt.com/v2/check-address/{check_id}/result', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

{}

{
  "detail": [
    {
      "loc": [
        "<string>"
      ],
      "msg": "<string>",
      "type": "<string>",
      "ctx": {},
      "input": "<unknown>"
    }
  ]
}

GET

check-address

{check_id}

result

Fetch the check-address result (charged once on success)

curl --request GET \
  --url https://api.aegis-kyt.com/v2/check-address/{check_id}/result \
  --header 'Authorization: Bearer <token>'

import requests

url = "https://api.aegis-kyt.com/v2/check-address/{check_id}/result"

headers = {"Authorization": "Bearer <token>"}

response = requests.get(url, headers=headers)

print(response.text)

const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};

fetch('https://api.aegis-kyt.com/v2/check-address/{check_id}/result', options)
  .then(res => res.json())
  .then(res => console.log(res))
  .catch(err => console.error(err));

{}

{
  "detail": [
    {
      "loc": [
        "<string>"
      ],
      "msg": "<string>",
      "type": "<string>",
      "ctx": {},
      "input": "<unknown>"
    }
  ]
}

Auth: Required · Billing: the check’s price, charged once here — not on submit · Use case: collect the verdict from POST /v2/check-address

Submission is asynchronous: the POST hands back a check_id and a result_url, and this endpoint is where the verdict arrives.

Request

curl -H "Authorization: Bearer aeg_YOUR_KEY_HERE" \
  "https://api.aegis-kyt.com/v2/check-address/3f8c1e2a-.../result"

Path param	Notes
`check_id`	From the 202 body of the submit call

Poll every few seconds. Typical completion is 5-90 s; a cold BFS on a high-degree address can take longer.

Response 200 — the verdict

{
  "schema_version": 1,
  "address": "TScSLnUodZVsgoGchZspDoimDjDB9bwqVv",
  "network": "TRON",
  "provider": "Aegis",
  "decision": "review",
  "verdict": {
    "ok": true,
    "risk_level": "medium",
    "risk_score": 50,
    "risk_categories": ["mixer-adjacent"],
    "consensus_found": true,
    "source_count": 3,
    "confidence": 0.78,
    "primary_source_slug": "graphsense-tag-pack",
    "label": "TornadoCash 1-hop",
    "sdn_match": null,
    "tier3_applied": true,
    "tier4_applied": false
  },
  "billing": {
    "model": "ledger",
    "currency": "USD",
    "charged_usd": "1.000000",
    "unit": "credits",
    "credits_charged": 1.0
  },
  "elapsed_ms": 320
}

verdict.tier3_applied / tier4_applied show which depth tiers ran — tier4_applied: false usually means too few transactions for a meaningful BFS, and Tier 0+1+2 still executed. For what decision means and how to act on it, see POST /v2/check-address.

Account risk policies

Some accounts have a custom AML risk policy configured (an operator-managed setting — for example, to stop flagging exposure to a specific counterparty that your compliance team has already reviewed and cleared). When a policy is active on your account and it had something to adjust for this specific check, the response carries an additional verdict.policy object alongside Aegis’s own verdict:

{
  "verdict": {
    "...": "...",
    "policy": {
      "id": "a1b2c3d4-...",
      "name": "...",
      "version": "1.0.0",
      "status": "applied",
      "risk_level": "medium",
      "risk_score": 42.0,
      "adjustments": [
        {
          "target_type": "vasp",
          "target": "...",
          "action": "ignored",
          "category": "sanctions_exposure",
          "contribution_before": 63.0
        }
      ],
      "guard": null,
      "clamped": false
    }
  }
}

verdict.policy is absent — not null — whenever no policy is configured for your account, or a policy is configured but found nothing to adjust for this particular check. Only check for the field’s presence, not its value.

Field	Type	Notes
`policy.id` / `name` / `version`	string	identifies which policy applied
`policy.status`	`"applied"` \| `"unavailable"`	`unavailable` means this check didn’t carry enough data for the policy to be evaluated — the base verdict is returned unchanged
`policy.risk_level` / `risk_score`	string / number	the policy-adjusted verdict
`policy.adjustments`	array	one entry per counterparty/category the policy suppressed or downgraded, with the risk contribution it removed (`contribution_before`, 0-100)
`policy.guard`	object \| `null`	non-null only when a hard floor (e.g. a direct sanctions match) overrides every policy — present but declined to change anything
`policy.clamped`	boolean	`true` if applying the policy would have raised risk above the base verdict — a policy can only ever lower risk, so the original verdict is kept instead

The top-level decision field and verdict.risk_level / verdict.risk_score always reflect Aegis’s own base verdict, computed before any account policy is applied — a policy never changes them. To see the policy-adjusted view, read verdict.policy.risk_level / verdict.policy.risk_score instead.

Other responses

HTTP	Meaning	Charged?
202	Still running. Body repeats `status` and `check_id`.	No
404	Unknown `check_id`, or it belongs to another key	No
502	The check itself failed — engine unreachable, address undecidable	No

404 does not mean “not finished”. It means this key cannot see that check — a wrong id, or someone else’s. A still-running check answers 202.

Billing — charged once, on delivery

The submit call never charges. This endpoint charges on the first 200 it returns for a given check_id, and never again:

Poll ten times before completion → ten 202s, no charge.
Poll again after the first 200 → same body, still one charge.
Check fails (502) → no charge at all.

So a retry loop is safe by construction; you do not need an idempotency key on the poll. (Idempotency-Key belongs on the submit, to avoid starting a duplicate job.)

Get started

Authentication

x402 Endpoints (USDC pay-per-call)

V2 Public API

Webhooks (push events)

Methodology

Reference

Other

GET /v2/check-address/{check_id}/result

Request

Response 200 — the verdict

Account risk policies

Other responses

Billing — charged once, on delivery

See also

Authorizations

Path Parameters

Response

​Request

​Response 200 — the verdict

​Account risk policies

​Other responses

​Billing — charged once, on delivery

​See also

Authorizations

Path Parameters

Response

Request

Response 200 — the verdict

Account risk policies

Other responses

Billing — charged once, on delivery

See also