Reduce IP false positives without loosening your rules.

The three false-positive reducers

When any reducer is true, the score is capped at 20 and benign_network_kind is added to reasons[]. It's a cap applied after the weighted sum — not a negative weight, not a block override. See the risk-score methodology.

One call, then a small branch

You don't need to special-case Apple, SpaceX or Google's resolver IPs yourself. One /v1/check call returns the signals and a score that already accounts for the benign cases:

const res = await fetch(`https://api.geoq.io/v1/check?ip=${ip}`, {
  headers: { "x-api-key": process.env.GEOQ_KEY },
});
const { signals, risk } = await res.json();

// Keep your strict datacenter / velocity rules. Carve out benign kinds:
const benign =
  signals.is_relay ||
  signals.connection_type === "satellite" ||
  signals.is_public_resolver;

if (benign) {
  // risk.score is already capped at 20; reasons[] includes benign_network_kind.
  allowWithLightFriction();
} else if (risk.level === "high") {
  blockOrReview();
}

Precision signals do the other half

Reducers stop you punishing good users. The routing and allocation signals help you catch the bad ones with more confidence, so you're not leaning on blunt rules that over-fire:

A note on what this is and isn't

An IP signal is one input, never a verdict. The reducers make GeoQ less likely to flag a real user, but they don't authenticate anyone — a relay or satellite exit just tells you the network kind is benign. Keep step-up friction (a captcha, an email check) for ambiguous cases, and don't make GeoQ the sole basis of an automated decision about a person. See the acceptable use policy.