numbers_per_client

What it cannot tell you

• It reads only your own account's single and browser lookups: batch, bulk and monitor runs, the test numbers and the guest demo never count, and no other account's traffic is read.
• It catches one script cycling numbers from one address, not an attack rotated through residential proxies. Without a client address the field is null and the signal cannot fire.

What to do

Challenge or rate-limit the client rather than the number. On its own it scores 30 and passes the default SMS policy, which blocks a score above 60; beside other signals the score can pass that.

The SMS policy is set per account with PUT /api/v1/phone/policy or the dashboard’s SMS policy tab, and its block_signals may list any signal, this one included; the phone guide lists every rule and its default.

Example response

An excerpt of an answer carrying this signal alone, with the number and the other fields left out, because no test number answers it. The score and the decision are worked out as the lookup and the default SMS policy work them out.

{
    "valid": true,
    "country": "GB",
    "line_type": "mobile",
    "line_type_source": "numbering_plan",
    "risk_score": 30,
    "risk_level": "medium",
    "risk_signals": [
        {
            "signal": "numbers_per_client",
            "weight": 30,
            "dataset": "account-velocity"
        }
    ],
    "client_velocity": {
        "distinct_numbers": 5,
        "window_minutes": 60
    },
    "ok_to_send": true,
    "blocked_by": null
}

A real answer carries every field, listed in the validate-phone reference; the weights of every entry in risk_signals sum to risk_score, capped at 100.