Sendity Client
Browser UI, server-owned verification.
The Sendity Web Client is the browser-side authentication surface. It renders the challenge code, channel actions, progress states and browser events while app configuration, channel routing and verification rules stay on the server.
Think of it as the visible edge of the flow: friendly enough to drop into a login screen, but deliberately thin from a security perspective. It can tell your frontend that a verification happened; it cannot decide that a user is authenticated. That decision stays with your backend or framework adapter.
Mount it where authentication happens.
Use the raw <sendity-auth> element or a framework adapter component in your login, signup or step-up flow. The Client owns the visible challenge and channel UI, but it does not create your application session by itself.
Let the server decide which channels exist.
The Client sends the public app id and current origin to the Sendity API. The API returns only the verification endpoints enabled for that app. This keeps recipients, channel availability and origin rules in server-side app configuration instead of scattering them through templates.
Verify before opening a session.
Browser events are UI signals. Your backend must verify the signed result, reject replay or expiry, map the verified subject to a local user and only then create the session. Framework adapters automate that path, but the trust boundary stays the same.
Runtime contract
The public contract is intentionally small: a public app id, optional rendering attributes, CSS custom properties and CustomEvent notifications. Secrets stay in your backend or the Sendity server. The Client never needs a client secret, because it should be safe to inspect every byte of the rendered page.
<script type="module" src="https://sendity.io/vendor/sendity/client/sendity-client.js"></script>
<sendity-auth
public-key="app_01HX..."
lang="en"
variant="no-card"
></sendity-auth>