Skip to main content
Bondify lets your users sign in with the messenger they already use — Telegram today, with WhatsApp and Discord on the way. One tap in the messenger and they’re in. No passwords to remember, no SMS codes to wait for, no third-party OAuth consent screens. You integrate once. Bondify handles the rest: the bot interaction, the session lifecycle, the cryptographic proof, and delivery to your backend.

Quickstart

Go from zero to a working Telegram sign-in in about five minutes.

How it works

The stateless, JWT-based proof model in technical detail.

React & Next.js

Drop-in @bondify/react provider, button, and hooks.

Backend verification

Verify the proof on your server before trusting any login.

​
Why Bondify?

Most auth solutions were built around email and passwords, then bolted on social logins as an afterthought. Bondify is built from scratch for messenger-native audiences — communities, mini-apps, SaaS products, and tools where your users already live in their messenger.

​
How it works

1

The user starts sign-in

Your app calls Bondify, which creates a pending session and opens Telegram with a deep link.
2

The bot asks for confirmation

The Bondify bot (or your own white-label bot) sends the user a confirmation prompt in Telegram.
3

The user taps Confirm

One tap — no typing. The session becomes confirmed.
4

Bondify issues a signed proof

Bondify mints a short-lived proof — a JSON Web Token signed with your project’s webhook secret — that carries the user’s Telegram identity.
5

Your server verifies the proof

Your backend verifies the proof locally (no round-trip to Bondify) and creates its own session — a cookie, JWT, or DB record, exactly as it already does.
The whole flow, from tap to confirmed, typically takes 3–5 seconds. If you prefer push over polling, configure a webhook and Bondify will POST the confirmed identity to you directly.

​
Core concepts

​
Project

A project is one integration — one app or environment. Each project carries three identifiers:
​
string (proj_…)
Public. Identifies your project in the browser, mobile SDK, and deep links. Safe to ship in client code.
​
string (sk_…)
Server-only. Authenticates server-to-server /generate and /verify calls. Never expose it in client code.
​
string (whsec_…)
Server-only. Verifies the proof JWT and webhook signatures. This is the value @bondify/node needs. Shown under Project → Settings → Webhook Secret.
secret_key and webhook_secret are two different server-side keys. Use secret_key to create sessions and webhook_secret to verify proofs and webhooks. Mixing them up produces an invalid signature error — see Backend verification.
You can create unlimited projects on the Pro and Business plans (Hobby is limited to one).

​
Session

A session is created the moment a user starts sign-in. It moves through a defined lifecycle:

​
Proof

When a session is confirmed, Bondify produces a proof: a JWT (HS256) signed with your project’s webhook_secret and valid for 5 minutes. Your server verifies it locally with that same secret — there is no verify-time round-trip to Bondify. See How it works for the exact payload.

​
Channel

The messenger used for authentication. Telegram is live today; WhatsApp and Discord are on the way. The SDK surface and the proof model stay the same across channels.

​
Plans

Billing is based on MAU — monthly active users, counted as unique Telegram accounts that confirm a sign-in, summed across all of your projects.
New accounts start on a 7-day free trial of Pro. When the trial ends, the account automatically moves to Hobby unless you subscribe. Over-limit MAU are billed at $0.02 each from a prepaid balance you top up — there are no automatic card charges for overage.

​
SDKs

Bondify ships official packages for the most common stacks. Pick the one that matches your app:

@bondify/react

React 18/19, Next.js 14–16. Provider, button, modal, QR, and hooks.

@bondify/node

Express/Node. Proof verification, middleware, and webhook handlers.

bondify_flutter

Flutter / Dart client for mobile apps.
No framework? Call the public REST endpoints directly — see HTML & Vanilla JS.