Crypto Exchange Lookup API Workflow for Automated Checks
The API route for crypto exchange lookups turns a one-time screening pass into a standing guard. The risk it manages is not a bad list — any tool can screen a list once. The risk is drift: an identifier with no exchange signal at snapshot time that quietly acquires one before payout, or an eligible account that lapses between announcement and distribution. One-time checks cannot see either movement. Scheduled API checks can. The tool behind the workflow: Crypto Exchange Lookup.
Quick answer
Screen on a schedule rather than only at milestones. Submit identifiers with your record IDs, store per-exchange results with timestamps, re-screen before every decision moment (airdrop snapshot, payout run, eligibility cut), and alert on newly-matched identifiers — those are the ones that appeared specifically to qualify.
What to send and what to keep
| Field | Direction | Purpose |
|---|---|---|
record_id |
Send | Joins results to the signup or wallet table. Text format; leading zeros die in spreadsheets. |
identifier |
Send | Email or phone, exactly as collected. Normalization is the check's job. |
exchange_results |
Receive | Per-exchange signal, not a blended boolean. Rules name exchanges; results should too. |
duplicate_flags |
Receive | Shared identifiers within the file — the sybil signature. |
checked_at |
Store | Per row, per run. Drift is a comparison, and comparisons need timestamps. |
Cadence: milestones plus one
Milestone screening is table stakes: at announcement, at snapshot, at payout. The run that catches fraud is the one after the last milestone. Airdrop farmers read the rules too, and they create qualifying accounts between snapshot and distribution precisely because everyone else stopped looking. A re-screen shortly before distribution costs a fraction of one round's rewards and regularly pays for itself in a single caught cluster.
For standing risk workflows (payout reviews, account-change checks), the check runs at the event, not on a calendar. The API exists so that "check before the money moves" is a line of code, not a person remembering.
Drift alerts worth building
- Newly matched: identifier had no signal at last run, shows one now. Short list, high value — review before rewards go out.
- Newly shared: an identifier that now appears across multiple accounts in the file. This is the sybil pattern forming in real time.
- Lapsed: matched at snapshot, unmatched now. Usually account deletion; matters for programs that require an active account at claim time.
Alerts should carry record IDs and both runs' results. A count without identifiers sends someone digging instead of deciding.
Retries and idempotent writes
Upsert on (record_id, run_id) as the write key. The same polled result arriving twice must not double-count a duplicate flag. Retry unknown rows after a few days — transient provider issues resolve on their own, and treating unknown as unmatched permanently corrupts the eligibility list with rows that were only sleeping.
What a year of runs looks like
Quarterly screening on a 40,000-identifier community base, illustrative shape:
| Run | Matched ≥1 exchange | Shared identifiers | Newly matched vs prior |
|---|---|---|---|
| Announcement | 52% | 3.1% | — |
| Snapshot | 55% | 3.8% | 4.2% |
| Pre-distribution | 56% | 4.0% | 1.9% |
(All figures here are illustrative examples, not product performance claims.)
The 1.9% newly matched just before distribution is the number the whole pipeline exists to produce. On 40,000 rows that is roughly 760 identifiers that qualified in the final window — exactly the population a sybil farm targets, and invisible to any one-time screening plan.
Mistakes to avoid
- One screening, ever. The list is a moving target. Milestone checks without a final pre-distribution pass are the standard miss.
- Storing snapshots over each other. No history, no drift, no alerts — just repeated one-time checks with extra steps.
- Auto-rejecting on flags. Exchange signals feed the review queue; your program's rules close the case. Keep the human in the loop through at least the first season.
- Ignoring failed lookups. Malformed identifiers should be repaired and re-run, not silently counted as unmatched.
FAQ
What is the output of the exchange lookup pipeline?
Account-signal status over time: per-exchange matches, duplicate patterns, and the drift between runs. The newly-matched and newly-shared lists are the deliverables.
How often should we re-screen?
At every program milestone plus once just before distribution. For risk workflows, at the transaction moment rather than on a calendar.
Webhooks or polling?
Polling. Screening runs on a schedule and nothing needs minute-level latency. Webhooks add idempotency burden without buying anything.
What should trigger an alert?
Newly matched identifiers, newly shared identifiers, and lapsed matches — each with row IDs plus both runs' outputs attached.
How do we handle unknown rows?
Retry after a few days, automatically. Escalate only what stays unknown across two runs.
Related ZelNum pages
- our exchange lookup walkthrough, walking through the interface.
- Best Crypto Exchange Lookup Tools for the tool selection angle.
Julian works on verification API integrations, batch jobs, CSV workflows, task polling, retry handling, result exports, and developer documentation. His guides explain how teams can integrate verification APIs safely and connect results with internal data systems.
View full author profile →