Ручная проверка одного адреса занимает минуту. Но когда через ваш обменник или бота проходят сотни клиентов в день, вручную проверять каждого невозможно. Здесь на сцену выходит AML-API — программный интерфейс, который принимает адрес и возвращает вердикт за доли секунды. В этом уроке разберём, как API устроен внутри, как встроить его в поток приёма средств и почему без автоматизации серьёзный сервис работать не может.
API (Application Programming Interface) — это «розетка», в которую ваша программа втыкает запрос и получает ответ. Вместо того чтобы открывать сайт, вставлять адрес в поле и читать отчёт глазами, ваш код отправляет адрес по сети и получает структурированный ответ — обычно в формате JSON. Разница как между тем, чтобы каждый раз ходить к колодцу с ведром, и тем, чтобы провести в дом водопровод.
Ключевая идея: вход — это адрес (и сеть), выход — это вердикт. Вердикт почти всегда состоит из трёх вещей: числового риск-скора (0–100), категории риска (например, mixer, sanctions, scam, exchange) и рекомендации (принять / проверить вручную / отклонить). Всё остальное — детализация: доли экспозиции, список рисковых контактов, глубина хопов.
Технически запрос — это обычный HTTP-вызов. Вы отправляете на адрес сервиса (endpoint) параметры и ключ авторизации. Схематично это выглядит так:
Запрос: GET /v1/check?address=0xABC...&network=eth с заголовком Authorization: Bearer ВАШ_КЛЮЧ.
Ответ (упрощённо):
{ "score": 78, "risk": "high", "category": "mixer", "exposure": { "mixer": 41, "exchange": 22, "unknown": 37 }, "verdict": "reject" }
Ваш код читает поле verdict и поле score — и на основе этого решает, что делать дальше. Никаких «глаз» и ручного чтения: всё превращается в ветвление в программе.
Разберём типовой сценарий: клиент хочет обменять USDT на рубли и присылает вам адрес, с которого придёт крипта (или адрес депозита, который вы ему выдали и куда он уже отправил средства). Правильный сервис проверяет адрес до того, как отдать деньги/рубли. Вот пошаговый поток.
score < 40 — авто-одобрение, сделка идёт дальше. Если 40–74 — уходит на ручную проверку оператору. Если ≥ 75 или категория sanctions/mixer — авто-отказ и удержание средств.Есть два способа получать данные: опрос (polling) — вы сами каждые N секунд спрашиваете «ну что, пришло?», и вебхук (webhook) — сервис сам стучится к вам, когда наступило событие. Вебхук эффективнее: вы регистрируете у провайдера свой URL, и он присылает POST-запрос, когда, например, по отслеживаемому адресу прошла новая транзакция или изменился риск-статус.
Каждый вызов API стоит денег или расходует квоту. Поэтому продуманная интеграция всегда включает: кэширование (не проверять один и тот же адрес десять раз за минуту — сохранить результат на несколько часов), ограничение частоты (rate limit, чтобы не упереться в потолок тарифа), и резерв на бота (если один и тот же ключ обслуживает и сайт, и бота — заложить, чтобы сайт не «съел» весь лимит). Это ровно та логика, что реализована в боевых системах: кэш + кап + резерв.
Материалы носят образовательный характер. Названия полей и форматы условны и зависят от конкретного провайдера.