A verified contact is a specific claim.
When Sendity verifies an identifier, it means an accepted channel supplied evidence of control during that verification. It does not mean Sendity checked a passport, established the person’s age or verified their physical address.
| Verified evidence | What it supports | What it does not establish |
|---|---|---|
| Aligned, DKIM-authenticated email | Control of the accepted sender email address during the flow. | Legal identity, exclusive mailbox access or permanent ownership. |
| Provider-observed WhatsApp number | Control of the WhatsApp account associated with that number during the flow. | Current SIM possession, a real name or continued control later. |
| Provider-observed SMS sender | The phone-channel evidence accepted under your campaign’s SMS policy. | Resistance to every carrier, forwarding or account-recovery attack. |
Names supplied by a user’s profile are presentation data. A friendly greeting can use that name; an identity decision should not.
Sender fields need independent evidence.
Email authenticity
An email can claim a sender address without proving it. Sendity’s email path requires DKIM to pass and align with the sender domain. A matching code without accepted email authenticity evidence does not complete the verification. Learn about email authenticity checks.
Official phone provider events
WhatsApp uses the direct Meta Cloud API. Sendity checks the raw-body HMAC signature, the configured account and business phone, the message timestamp and the provider message ID. It requires a provider-observed phone number; a username, display name or business-scoped user ID alone is insufficient.
SMS uses the supported provider’s authenticated webhook and the application’s channel policy. Unofficial messenger clients, scraped sessions and arbitrary contact cards are not accepted as phone proof.
The message must belong to this request.
The short code connects an incoming message to an active challenge. It has an expiry, and the accepted sender evidence must satisfy the request’s channel rules. Provider message IDs are deduplicated so delivery retries cannot be treated as fresh verification events.
Configure your allowed website origins and keep application credentials and provider secrets on the server. A public client key identifies your application; it is not a substitute for backend authorization.
Production operation also matters. Shared cache and locks coordinate challenges and deduplication across instances. Monitor failed provider deliveries and signature errors, and keep the runtime and dependencies updated. Open-source code makes these paths inspectable; it does not run or secure a deployment by itself.
The browser is a user interface, not an authority.
A completed widget or JavaScript event can help your page move forward. It must not be enough to grant access. Your backend needs to validate the signed authorization, its expiry and its intended application before trusting the verified identifier.
Use the supported backend integration to create or find an account, issue your own application session or approve the pending operation. Keep account linking, roles, consent and business permissions explicit. A verified number is not permission to merge two accounts or authorize an unrelated payment.
Plan for the risks a channel cannot remove.
A compromised email or WhatsApp account can produce authentic messages. Social engineering can persuade someone to send an attacker’s challenge. Phone numbers can change hands, and shared devices can expose accounts to more than one person. Code-based channel verification is not automatically phishing-resistant.
Use clear action context, appropriate session lifetimes, abuse controls and a considered recovery policy. For higher-risk journeys, assess whether passkeys or another stronger factor are appropriate. Never describe contact verification as a guarantee of identity or fraud prevention.
Choose hosted or self-hosted Sendity based on how you want to operate the service, and review the privacy information for the hosted service.