DEV Community: Ilya-hye

Stateless auth without a database round-trip: how Bondify's proof model works

Ilya-hye — Thu, 02 Jul 2026 16:47:33 +0000

The shape of the problem

Most "login with X" integrations work the same way: your server gets a token, and to find out if it's real, it has to ask the provider. That round-trip is one more network call on your auth hot path, one more thing that can time out, and one more dependency between your uptime and theirs.

Bondify doesn't do that. Verification is local — a single HMAC check against a secret only you and Bondify know. No call back to api.bondify.dev is required to trust a login. Here's how that's possible, and what it buys you.

The flow

Create a session

Your client calls the public generate endpoint (or your server calls the secret-key version). Bondify returns a deeplink, a session_token, and an expires_at.
Open Telegram

The client opens the deep link — https://t.me/<your_bot>?start=<session_token> — and the user lands in your bot.
Confirm in Telegram

The user taps Confirm. Bondify marks the session confirmed and attaches the Telegram identity to it.
Detect confirmation

Your client polls verify (the SDK does this for you), or your server polls it, or — better — you skip polling entirely and let a webhook push the result to you.
Verify on your backend

The verify response includes a signed proof. Your server checks the signature locally. If it's valid, you mint your own session — cookie, JWT, whatever you already use.

Step 5 is the part worth dwelling on, because it's where the "no round-trip" property actually comes from.

What's inside a proof

A proof is a JWT, signed with HS256. Decode it and you get something like:

{
  "telegram_id": "123456789",
  "telegram_name": "Ada Lovelace",
  "telegram_username": "ada",
  "project_id": "proj_xxxxxxxx",
  "session_token": "a1b2c3d4e5f6",
  "iss": "bondify",
  "iat": 1700000123,
  "exp": 1700000423
}

Nothing exotic. The interesting part isn't the payload — it's the signature. The token is signed with your project's webhook secret (whsec_…):

HS256(header.payload, webhook_secret)

The proof is signed with the webhook secret, not the secret key (sk_…). The same whsec_… verifies both proofs and webhook signatures, so your backend only needs to manage one secret for both flows.

Because only your server and Bondify know whsec_…, a valid signature is proof (hence the name) that Bondify issued the token and that nobody tampered with the payload in transit. Your server can check this with one line of JWT-library code and zero network calls:

import { BondifyServer } from '@bondify/node'

const bondify = new BondifyServer({
  jwtSecret: process.env.BONDIFY_WEBHOOK_SECRET!,
})

const user = await bondify.verifyProof(proof)
// user.telegram_id, user.telegram_name, user.telegram_username

That's the entire trust boundary. No HTTP client, no timeout handling, no "what if Bondify's API is slow right now" — just a synchronous cryptographic check that either passes or throws.

Why this matters more than it sounds like it should

It's tempting to read "saves one HTTP call" and shrug. In practice it changes three things:

Latency is bounded by your own infrastructure, not ours. Your login endpoint's p99 no longer includes a leg to a third-party API. If Bondify has a bad five minutes, sessions that already reached confirmed still verify — because verification never asked Bondify in the first place.
There's one fewer thing that can go down in your critical path. A network partition between your backend and Bondify's API doesn't fail logins that have already produced a proof.
The security boundary is auditable in isolation. "Is this login real?" reduces to "does this HMAC check pass with this secret?" — a property you can unit test without mocking an HTTP client.

This is the same reason JWTs displaced server-side session lookups in a lot of API design: shifting verification from ask the source of truth to check a signature from the source of truth turns a remote dependency into a local computation.

The properties that make it safe to do this

Self-contained tokens are only as trustworthy as their constraints. Bondify's proof has three:

It expires fast

A proof's exp is 5 minutes after issuance. Standard JWT libraries reject it automatically once expired, so "verify promptly" isn't a suggestion you have to remember — it's enforced by the format. Don't cache a proof and check it later; check it the moment you receive it.

It's single-use

A session can be read once via the verify endpoint. The first confirmed read flips it to used, and it will never produce another proof after that. There's no scenario where the same proof gets handed to two different backends and both accept it.

The signing secret never touches the browser

The webhook_secret and secret_key live only on your server. The browser only ever sees the public project_id, which can start a session but cannot verify proofs or call management endpoints. Even if someone inspects your frontend's network tab, there's nothing there to forge a proof with.

A proof that passes signature verification is sufficient to trust the Telegram identity inside it — you don't need to call Bondify's API again to "double check." Re-verifying server-side adds latency without adding security, since the HMAC already proves provenance.

Where webhooks fit in

Polling step 4 above works, but for most backends a webhook is the better default: Bondify pushes the confirmed identity to your endpoint the moment it happens, signed the same way (X-Bondify-Signature, HMAC-SHA256 over the raw body, same whsec_…). No proof JWT is involved there — the webhook carries the identity directly, and the signature is the trust mechanism. We'll cover the delivery and retry semantics in a follow-up post.

What Bondify intentionally doesn't store

The stateless design extends to data retention. Bondify keeps Telegram identity (telegram_id, telegram_name, telegram_username), session metadata, and — only if you've enabled phone collection on Pro/Business — telegram_phone. No passwords, no OAuth tokens, nothing your backend doesn't already need to make its own decision about who the user is.

If you're integrating this for the first time, the quickstart walks through generating a session and verifying a proof end to end in about fifteen minutes.

What SMS OTP actually costs you, beyond the Twilio invoice

Ilya-hye — Thu, 25 Jun 2026 15:10:29 +0000

If your signup flow sends a text message, you already know it costs money per send. What's less visible on the invoice is everything SMS OTP costs you that never shows up as a line item: the users who bounce waiting for a code, the toll-fraud traffic nobody noticed until the bill doubled, and the engineering hours spent handling carrier edge cases that have nothing to do with your product.

This isn't an argument that SMS is broken in some abstract sense - it's an argument that for an auth step specifically, you're paying for properties you don't need and not getting the one you do.

The direct cost is the easy part to see

Twilio-style SMS pricing for OTP sits roughly in the $0.03–$0.08 range per message depending on destination country, and that's before you account for delivery retries when a carrier silently drops the first attempt. At 10,000 monthly active users, each going through login at least once, you're looking at somewhere between $300 and $800 a month - for a step that, conceptually, is just "prove you control this identifier."

Compare that to what a messenger-based login costs structurally: nothing per-message, because there's no message to send through a paid carrier route. Bondify's Pro plan covers 10,000 MAU at a flat $20/month, with overage at $0.02 per additional MAU beyond that, paid from a balance you top up once - no auto-charging.

The gap isn't a rounding error. It's the difference between a cost that scales linearly with every login attempt - including failed ones - and a cost that scales with monthly active users, a number your business already has reasons to track and forecast.

The cost that doesn't show up on an invoice: conversion

SMS OTP adds a wait. The user submits a phone number, switches to their messages app - assuming they're on the device that number belongs to - finds the code among whatever else is in their inbox, switches back, and types six digits correctly before a timer expires. Every one of those steps is a place to lose someone, and aggregate signup-funnel data across SMS-gated flows consistently shows meaningful drop-off at the OTP step specifically, not before it.

A messenger-based tap collapses that into: tap a button, tap Confirm in an app that's usually already open, done. There's no code to transcribe and no context switch to a different app entirely - Telegram's deep link opens the bot, the user taps once, and control returns to your product. The mechanism that makes this possible is the same stateless proof system covered in our architecture post - your backend gets a verifiable identity assertion the instant the user confirms, without your frontend having to manage a code-entry UI at all.

The cost nobody budgets for: fraud

Toll fraud - bots requesting OTPs to numbers that rack up premium-rate charges, or simply burning through your SMS budget to see what sticks - is a known failure mode of any flow where "send a text" is reachable by an unauthenticated request. Every fraudulent OTP request is a real charge from your SMS provider, and the attack scales as fast as a script can hit your endpoint.

There's no equivalent surface here, because there's no per-attempt cost to externalize. Generating a Bondify session doesn't dispatch a billed message to a phone number you haven't verified belongs to anyone - it produces a deep link that does nothing until a real Telegram account taps Confirm. An attacker spamming your generate endpoint costs you nothing per request, which removes the financial incentive that makes OTP-bombing worth attempting in the first place.

The cost that's hardest to estimate: integration time

A from-scratch OTP flow isn't just "call an SMS API." It's a backend service to generate and store codes with expiry, rate-limiting on both the request and verify steps, a UI for code entry with resend logic, and a long tail of carrier-specific edge cases - messages that arrive out of order, numbers that get reassigned, countries where delivery is unreliable enough that you build a fallback provider.

The integration surface for messenger auth is smaller because there's less surface to begin with: no code-entry UI, no resend timer, no message delivery to monitor. The quickstart covers generating a session, redirecting to Telegram, and verifying the result - the kind of thing that fits in an afternoon rather than a sprint, precisely because the hard parts (signing, session lifecycle, replay prevention) are already handled on Bondify's side.

Where SMS still makes sense

To be fair to SMS: it doesn't require the user to have a messenger account, and it works on devices with nothing installed beyond the phone app. If your user base skews toward demographics or regions where Telegram penetration is low, that's a real constraint worth weighing - messenger auth is a bet on your users already being on the platform, not a universal replacement for phone-number verification as a concept.

What it isn't a good fit for is the common case this post is about: a SaaS or app where your users already have Telegram (or soon, WhatsApp and Discord) installed, and where the per-login cost and conversion drag of SMS are pure overhead relative to a one-tap alternative.

Trying it without committing to anything

Bondify is currently in Public Beta, and the platform is 100% free to use right now while we stress-test our database.

Every new developer account automatically gets a 7-day Pro trial with custom bot support and phone number collection enabled. Since our automated billing is currently paused during the beta, if you need to extend your Pro features or increase your limits, just drop us a message inside the dashboard, and we’ll manually upgrade your workspace for free.

The Hobby plan covers up to 1,000 MAU at $0 forever. If the numbers above hold for your funnel, check out our documentation and ship messenger-based auth in 15 minutes!