Docs / Honeypot Lookup API

Honeypot Lookup API

Ask whether a phone number is a known honeypot before you dial it, and how many times we have detected it. One indexed lookup, answered in milliseconds, against 13.3 million confirmed detections. $499/month, paid from your account balance.

Quick start

curl -H "X-API-Key: $KEY" \
  "https://app.amdy.io/hp/v1/honeypot?phone=15203074037"

{
  "phone": "5203074037",
  "honeypot": true,
  "detections": 167,
  "distinct_vids": 164,
  "client_ips": 68,
  "first_seen": "2026-07-20T17:38:19-04:00",
  "last_seen": "2026-09-18T15:54:29-04:00"
}

honeypot is the yes/no answer and detections is how many times we have seen it. Send 10 or 11 digits; a leading US 1 is stripped for you.

Getting a key

Subscribe and issue keys at app.amdy.io → Honeypot protection. Honeypot keys start with amdy_hp_ and are shown once, at creation. We store only a SHA-256 hash, so a lost key cannot be recovered, only replaced.

Either header works:

X-API-Key: amdy_hp_xxxxxxxxxxxxxxxx
Authorization: Bearer amdy_hp_xxxxxxxxxxxxxxxx

The portal shows, per key, whether it carries the honeypot service, so you can tell at a glance which of your keys can call this API.

Endpoints

Batch

curl -H "X-API-Key: $KEY" -H 'Content-Type: application/json' \
  -d '{"phones":["15203074037","12282391666","18162069387"]}' \
  https://app.amdy.io/hp/v1/honeypot/batch

Malformed entries come back in invalid instead of failing the whole request. Batch is the right call for list scrubbing: one round trip for a thousand numbers.

Errors

The split between 401 and 403 is deliberate: your code can tell a bad credential from a lapsed subscription without guessing.

What it can and cannot tell you

A false is not proof a number is safe. The API answers from the set of calls we have classified as honeypot. A number we have not seen, or repeatedly misclassify, answers false.

• Use it as a positive check. A true is high confidence and worth acting on: suppress the number. A false means "not known to us", not "clean".
• Coverage grows. Numbers are added continuously from live detections and after-the-fact verification, so a false today can become true next week. Re-check lists periodically instead of caching a negative forever.

Why it is fast: the lookup hits a purpose-built, phone-indexed table. The full detection log is about 2.6 TB with no phone index, where the same question takes roughly a minute per day of history. This service exists so you do not pay that cost.

Billing and limits

$499 per month, charged from your account balance on the same day each month. The first month is charged when the service is enabled. Cancelling leaves the service running until the end of the month you have already paid for.

There is no daily, hourly or monthly quota. Two limits protect the index, which is the product:

• Requests per second: 20 per account by default (raised per arrangement). Each request counts once, a single lookup or a batch of up to 100 numbers. Above the limit you get 429 with Retry-After: 1. Your /usage endpoint shows lookups per day.
• No sequential querying. This service screens the calling lists you already have. Walking the number space (runs of consecutive numbers, in single requests or across requests) is refused with 429.

If a legitimate list contains a block of consecutive numbers (a company's own DIDs), that is fine in normal quantities; the sequential check trips only on long runs.

Wiring it into a dialer

See Honeypot scrubbing for VICIdial, Asterisk and FreeSWITCH for working scripts: scrub a file before you load it, scrub leads already in VICIdial on a cron, or check at dial time from the dialplan.

Dialer integration guide · Back to docs