The website starts. The visitor sends.
OTP means one-time password. In a familiar outbound flow, a visitor supplies an address or number, waits for a message and brings the code back to the page. Reverse OTP is a useful way to describe the opposite direction.
Sendity creates a short-lived challenge for the current request. The visitor opens a prepared email or WhatsApp message, presses Send and returns to the original browser. Sendity checks the incoming message and its sender evidence before completing verification.
The visitor’s accepted sender address or provider-observed number becomes the verified identifier. That removes the need to ask them to type the same contact into a separate field first.
Reversing a code is not enough on its own.
Any system can receive a string of digits. Verification needs a trustworthy connection between the message, the sender and the live challenge. A forged sender field or copied profile name cannot provide that connection.
Sendity’s email channel requires DKIM verification with domain alignment. Its WhatsApp channel authenticates an official Meta webhook and requires a provider-observed phone number. The challenge must still be valid, and your backend must validate the signed result.
A different route to a usable contact.
Fewer contact-entry steps
The address or number comes from the accepted message evidence. The visitor does not need to retype it into a contact field, which can avoid that source of typing errors.
No outbound code delivery on the ordinary path
For a typical WhatsApp verification with a visible sender number, the visitor’s message carries the code. Your service does not have to purchase an outbound authentication template to deliver that challenge. This changes the underlying cost structure; extra messages, provider rules and the verification service itself still have costs. Read the WhatsApp cost explanation.
A reusable step in your product
The same verification can support a webinar registration, a newsletter sign-up or account access. Your application decides the outcome and records any separate consent it requires.
Fit the flow to the moment.
The user needs to control a supported account, send the message and return to the browser. On desktop, this may involve scanning a QR code with a phone. Mail configuration, provider availability or hidden phone numbers may require another step or another channel.
Measure completion in your own audience and journey. Reversing message direction does not guarantee a conversion improvement, prove legal identity or make the flow automatically phishing-proof.
For a form that needs a verified contact, it can be a practical alternative to a contact field followed by an outbound code. For a high-risk authorization, decide what additional authentication and context your application needs.