Developer documentation
Where identity signals come from
AbuseZero never scrapes your users. Every fact in an evaluation comes from fields your trusted backend (or optional browser SDK) sends, with defined semantics per signal.
Email and verification
Your authenticated backend sends the end user's email. Send email_verified only when your own authentication system has verified ownership. AbuseZero records the assertion; it does not verify the mailbox during an evaluation.
Email matching
Email history matches the mailbox, not the exact spelling. Letter case is ignored, googlemail.com counts as gmail.com, and Gmail ignores dots. +tags are ignored for Gmail, Outlook, Hotmail, Live, MSN, iCloud, me.com, mac.com, Proton, and Fastmail addresses. Send the address exactly as your user entered it; AbuseZero applies these rules itself.
Client IP
When available, your backend sends context.ip after resolving the client address through its trusted proxy chain. Do not send your application server's address. IPv4 and IPv6 are supported. You may omit the field or send null; AbuseZero records IP facts as not supplied and continues with the other evidence. Neither SDK automatically fills this field.
IPv6 matching
IP history and attempt counts for a public IPv6 address include its whole /64 network, because one subscriber or server normally controls all of it. IPv4 addresses match exactly. Test IPs in 2001:db8::/32 also match exactly, so each Test IP stays an independent scenario.
Payment fingerprint
Read the provider-issued fingerprint from trusted payment-provider server data and send it with the provider and account scope. AbuseZero matches the whole scoped value. It does not detect the fingerprint, inspect card details, or accept raw payment data.
{"payment":{"provider":"stripe","scope":"acct_123","fingerprint":"provider-issued-fingerprint"}}Verified phone
Normalize the phone number to E.164 in your backend, then use the Node helper with a customer-owned HMAC secret. Send the hash and phone_verified together. Without the hash, the phone fact is not supplied—not false.
Custom identifiers
Register a key and key version in Settings, then hash the normalized value in your backend with the Node helper. Multiple key versions can coexist during rotation. Custom identifiers are matching inputs, not arbitrary metadata or customer-created policy facts.
{"custom":[{"key":"license_id","value_hash":{"algorithm":"hmac-sha256","key_version":"v1","value":"64-lowercase-hex-characters"}}]}What AbuseZero stores
Matching identifiers are stored as organization-and-environment-scoped keyed hashes. Original retained evaluation evidence is encrypted for authorized diagnostics. Do not send raw phone numbers, card details, postal addresses, arbitrary metadata, or customer HMAC secrets.