Stop Coupon Farms Without Banning a Building: IP Risk at Claim Time

Yesterday’s playbook for bulk signup still applies when the prize moves downstream: new-user coupons, referral bonuses, and first-order subsidies. Promo farms rarely need a datacenter flood. They rotate residential or dial-up exits, sometimes through cloud phones, claim once per identity surface, and leave. A static “block all hosting” rule misses most of that traffic; a hard ban on every flagged address can still take out a whole building on shared broadband.

IP99 by ThreatHunter gives you a free GET /v1/ip/{ip} answer you can call at claim time: typed signals (proxy, dialup_pool, cloud_phone, …), evidence_state, and a 0–100 score that measures freshness and strength of verifiable evidence — not “probability this shopper is an attacker.”

Why claim time is a different gate than signup

Signup gates care about account inventory. Promo gates care about burn rate on a finite budget. The same egress pattern shows up for both, but the cost of a false hard-ban is different: locking out a CGNAT neighborhood during a flash sale can spike support tickets and kill conversion faster than a delayed coupon.

Typical claim-side patterns:

If your coupon service only asks “is this IDC?”, you are still fighting last decade’s inventory. Weekly public aggregates on proxy exits keep showing that newly captured proxy-class addresses are overwhelmingly off datacenter space — so residential allowlists are not a promo shield.

A claim-time triage (step up, don’t flatten the building)

Official reading order on IP99 is still: evidence_state → score/level → which signals → (only if you ever ban) share scope. On the free API you do not get Pulse share_tier; usage_type plus evidence_state is enough for a coupon funnel:

1. evidence_state: none — no current evidence. Do not mark the claim “safe.” Keep normal fraud checks (device, payment, velocity).
2. stale — seen before, evidence aged out, score 0. Weak feature only; do not deny the coupon alone.
3. active + low (1–29) — log, optional soft friction (email confirm, slower claim, cap per ASN//24 for the campaign hour).
4. active + medium (30–69) — step up before payout: captcha, second factor, delay grant, or hold the reward for manual/risk review — prefer verify over IP ban when usage_type is DYN or MOB.
5. active + high (70–100) — decide by campaign burn. Still prefer challenge + delay on shared residential/mobile egress. If hijacked_proxy is present, treat the household as likely collateral: challenge the session, do not permanently ban the address for a promo.

Signal choice matters for how you step up: cloud_phone and dialup_pool are stronger promo smells than bare hosting (a network attribute — Google Public DNS carries hosting with score 0). crawler is benign and does not participate in scoring; do not treat search-engine exits like coupon farms.

Live curls (2026-10-25, no API key)

Anonymous quota is 500 lookups/day per client IP (60/min). Sign in for 5,000/day. Overseas self-serve Pro / Pro+ buys volume only ($29 / $99) — same evidence fields, not a “better score.” Professional evidence detail and ?at= history are a separate contracted tier.

# Egress you are about to claim from
curl https://ip99.com/v1/ip

# Public demo address often used in IP99 docs (mask last octet in tickets)
curl https://ip99.com/v1/ip/27.22.66.200

# Datacenter control: hosting attribute, score 0 — not a promo farm by itself
curl https://ip99.com/v1/ip/8.8.8.8

# Remaining anon quota
curl https://ip99.com/v1/me

Sample: residential dial-up / proxy supply (mask last octet)

Captured ~2026-10-25 13:12 UTC. Full address works in the curl above.

{
  "ip": "27.22.66.x",
  "computed_at": "2026-10-25T13:12:11Z",
  "evidence_state": "active",
  "degraded": true,
  "geo": {
    "country": "CN",
    "region": "Hubei",
    "city": "Xiangyang",
    "district": "Nanzhang",
    "admin_code": "420624",
    "tz": "Asia/Shanghai"
  },
  "network": { "asn": 4134, "usage_type": "DYN" },
  "risk": {
    "score": 20,
    "level": "low",
    "signals": ["dialup_pool", "hijacked_proxy", "proxy"]
  }
}

Read left to right: still DYN home broadband; signals say dial-up pool + proxy presence; hijacked_proxy warns the line owner may be a victim; evidence_state: active with a low score means friction at claim time, not a permanent ban. degraded: true means part of the feed was unavailable — treat the answer as soft. Scores move as evidence ages; the same IP an hour later can look different on purpose.

Sample: hosting control

{
  "ip": "8.8.8.8",
  "evidence_state": "none",
  "network": { "asn": 15169, "usage_type": "IDC" },
  "risk": { "score": 0, "level": "none", "signals": ["hosting"] }
}

hosting alone is not a reason to deny a coupon. Pair typed proxy-class signals with campaign velocity and payment risk.

Wire it where the budget burns

Call the lookup on your server with the client’s real egress (reverse proxies lie if you only trust X-Forwarded-For without a trusted hop list). CORS is open on /v1/ip, but clients can forge their IP — keep the gate server-side.

Minimal shape for a claim endpoint:

1. Resolve public client IP.
2. GET https://ip99.com/v1/ip/{ip} (optional X-API-Key when you outgrow anon).
3. Branch on evidence_state then risk.level / risk.signals as above.
4. Persist computed_at, score, signals, and your decision for dispute review later.

Free /v1/ip answers now. “What did we know when this coupon was granted?” needs Pulse ?at= (professional contract). Do not invent historical replay on the free tier.

Import the contract from https://ip99.com/openapi.json into Postman or codegen if you want typed clients. Agents can use the same lookup as MCP tool ip_risk_lookup at https://ip99.com/mcp.

What this article is not claiming

• No Tor signal — do not invent one.
• Risk score ≠ attacker probability.
• IP99 public API evidence and ThreatHunter enterprise feeds are related products, not “the same data.”
• Mask real home or mobile customer IPs in tickets and screenshots.

Paste a claim egress into ip99.com or run the free curls above. If you are shipping referral or new-user campaigns, start with evidence_state + typed signals at claim time, and keep hard IP bans rare — especially on shared residential and mobile egress.