Docs overview
Understand the Sendity authentication flow.
Sendity is channel-control authentication: the user proves control over an enabled channel by sending back a short challenge code. Sendity verifies the proof and returns a signed result; your application verifies that result before creating its own session.
Authentication flow
One linear proof lifecycle.
-
The Client creates a challenge.
The Sendity Client runs in the browser with a public app id and calls the Sendity API from an allowed origin.
-
The Server resolves the channel.
Enabled channels and verification destinations are configured server-side for the app; the browser does not hardcode recipients.
-
The user sends the proof.
Sendity receives the message, matches the challenge code and marks the verification as successful.
-
Your backend verifies the result.
Treat browser events as signals only. Verify the signed result on the server, reject replay or expiry, then create your local user session.
Building blocks
Follow the part that matches your integration.
Sendity Client
The browser Custom Element renders the authentication UI, creates challenges, emits events and hands the signed result to your application.
Read Client docsLaravel adapter
The adapter renders the Client, validates the signed result server-side, protects against replay and connects the proof to your Laravel session.
Read adapter docsSendity Server
The hosted or self-hosted API owns apps, allowed origins, enabled channels, challenge lifecycle, incoming proofs and token issuance.
Read Server docsStart integrating
Most applications start with Sendity Cloud, the Sendity Web Client and server-side result verification. Add the Laravel adapter when you want framework-native session handoff; use self-hosting only when your team needs to operate the verification backend itself.