Overview

NoResponse tells you how risky a new account is before your platform creates it or hands it free credits. Your backend makes one call at signup or login with the email, username or phone the person typed. NoResponse looks the identifiers up and answers within 500 ms.

The lookup covers the accounts the person holds elsewhere, breach, credential-list and stealer-log exposure, phone intelligence (line type, carrier, spam reports and caller-ID names), IP intelligence (VPN, proxy, Tor, hosting and country), and your platform’s own history: repeat identifiers, shared IPs and the outcomes you report.

The answer is an assessment. It carries a risk score from 0 to 100, the reasons that moved the score, and a recommendation of allow, step_up or review. Your code applies the recommendation with its own rules, so you keep control of what happens to the account.

The part of every answer you act on

{
  "status": "partial",
  "risk": {
    "score": 8,
    "band": "low",
    "recommendation": "allow",
    "confidence": "medium",
    "reasons": [{ "code": "new_email", "weight": 8, "identifier": "email" }]
  }
}

The standard answer carries the score, the reasons and typed summary facts per identifier, such as how many accounts the email has, whether the phone is VoIP and whether the IP is a proxy. The detailed view adds the breach tables that matched and one signal per source answer.

How a call goes

1. Your signup route calls POST /v1/assessments with the identifiers and an Idempotency-Key.
2. NoResponse answers within 500 ms. Most answers carry a recommendation.
3. Your code applies its own rules to the score and reasons, then creates the account, asks for a second factor or queues it for your team.
4. If sources were still answering, a signed webhook delivers the updated assessment. Your code runs the same rules again.
5. Later, your platform reports what the account turned out to be, so the next score for that person is better.

The three statuses

Every assessment has a status.

Status	HTTP	What it means
complete	200	Every source answered or failed for good. The score will not move.
partial	200	A recommendation exists, but at least one source is still answering. The score can still move.
pending	202	No source answered before the deadline. There is no score and no recommendation yet.

partial is the status to read carefully. The answer is usable, and your code can act on it, but a later revision can change it. One real signup answered partial with a score of 8 and allow. Five seconds later the same assessment was complete with a score of 33, after the accounts source answered. Each revision has a higher assessment_version, so store the version you acted on beside the decision. Pending, retries and idempotency explains how to wait for the final answer, and Webhooks explains how to receive it.

pending has no recommendation. Your code applies the fallback you chose for that case. Assess signups and logins sets out the two choices.

Ten terms

The rest of this site uses these words.

Term	Meaning
Assessment	One answer about one signup or login. It has an assessment_id that starts with asm_ and lives for 365 days by default.
Account id	Your platform’s own opaque id for the account, sent as account_id. It travels in the body, not the URL.
Identifiers	What NoResponse looks up: at least one of email, username or phone. name and ip sharpen the match.
Risk score	risk.score, from 0 (safe) to 100 (risky). It is the sum of the weights of the reasons that fired, clamped to that range.
Band	risk.band: low for 0 to 29, medium for 30 to 59, high for 60 to 84 and critical for 85 to 100.
Recommendation	allow, step_up or review. The same value appears at the top level and as risk.recommendation.
Reasons	risk.reasons, every reason that fired with its weight and, where it applies, the identifier it concerns. The codes are stable.
Status	complete, partial or pending, as above. A webhook can also carry expired, which means the assessment is gone.
Source	One place NoResponse asks about an identifier. Sources are counted in risk.coverage and grouped into the lanes accounts, phone, breach and ip in incomplete_sources.
Policy version	policy_version, the version of the weights that produced the recommendation. Store it with each decision so you can explain the decision later.

Start here

QuickstartInstall an SDK, set your key and assess one signup in five minutes.

Assess signups and loginsThe full request and the fallback you choose for pending and errors.

Turn an assessment into a decisionOrdered rules you can copy and tune.

API referenceEvery endpoint, with a playground that sends real requests.