Checking one address by hand takes a minute. But when hundreds of clients a day pass through your exchanger or bot, checking each one manually is impossible. This is where the AML API steps in — a programmatic interface that takes an address and returns a verdict in a fraction of a second. In this lesson we break down how the API works inside, how to embed it into the incoming-funds flow, and why a serious service cannot operate without automation.
An API (Application Programming Interface) is the "socket" your program plugs a request into and gets an answer back. Instead of opening a website, pasting an address into a field and reading a report with your eyes, your code sends the address over the network and receives a structured answer — usually in JSON format. The difference is like walking to the well with a bucket every time versus running plumbing into the house.
The key idea: the input is an address (and a network), the output is a verdict. The verdict almost always consists of three things: a numeric risk score (0–100), a risk category (for example, mixer, sanctions, scam, exchange) and a recommendation (accept / check manually / reject). Everything else is detail: exposure shares, a list of risky contacts, hop depth.
Technically a request is an ordinary HTTP call. You send parameters and an authorization key to the service's endpoint. Schematically it looks like this:
Request: GET /v1/check?address=0xABC...&network=eth with the header Authorization: Bearer YOUR_KEY.
Response (simplified):
{ "score": 78, "risk": "high", "category": "mixer", "exposure": { "mixer": 41, "exchange": 22, "unknown": 37 }, "verdict": "reject" }
Your code reads the verdict field and the score field — and decides what to do next based on them. No "eyes" and no manual reading: it all turns into a branch in the program.
Let's work through a typical scenario: a client wants to swap USDT for rubles and sends you the address the crypto will come from (or the deposit address you gave them, to which they have already sent the funds). A proper service checks the address before handing over money/rubles. Here is the step-by-step flow.
score < 40 — auto-approval, the deal proceeds. If 40–74 — it goes to an operator for manual review. If ≥ 75 or the category is sanctions/mixer — auto-rejection and holding of the funds.There are two ways to get data: polling — you yourself ask "well, has it arrived?" every N seconds, and a webhook — the service knocks on your door itself when an event occurs. A webhook is more efficient: you register your URL with the provider, and it sends a POST request when, for example, a new transaction has passed through a watched address or its risk status has changed.
Every API call costs money or consumes quota. That is why a well-thought-out integration always includes: caching (don't check the same address ten times a minute — save the result for a few hours), a rate limit (so you don't hit the ceiling of your plan), and a reserve for the bot (if the same key serves both the site and the bot — set aside enough so the site doesn't "eat" the whole quota). This is exactly the logic implemented in live systems: cache + cap + reserve.
This material is for educational purposes. Field names and formats are illustrative and depend on the specific provider.