A bot on the same API as your website

We have built Telegram and WhatsApp bots for several clients, for order status, rates and balances, FAQs and notifications. They sit on the same API as the client’s website. On one Laravel and Next.js platform, a Telegram bot handles rate, portfolio and transaction queries and notifications, as a first-class interface alongside the web app.

The rule follows from what goes wrong otherwise. If a bot has its own price calculation, sooner or later the bot and the website will show different numbers. Then you have a support problem and a trust problem. So the bot should know about chat, and nothing else about your business.

The Bot API gives two mutually exclusive ways to receive updates: long polling with getUpdates, or a webhook. On a web application, use a webhook. Set a secret when you register it, and check that it comes back on each request:

if (! hash_equals(config('services.telegram.secret'),
    (string) $request->header('X-Telegram-Bot-Api-Secret-Token'))) {
    abort(403);
}

ProcessTelegramUpdate::dispatch($request->all());

return response()->noContent();

Respond quickly and do the real work in a queued job. Telegram treats anything other than an HTTP 2XX as a failure and retries, so the job must be safe to run twice: store each update_id and ignore repeats. Telegram keeps undelivered updates for no longer than 24 hours, so a long outage loses messages. Webhooks are supported on ports 443, 80, 88 and 8443.

A chat ID isn’t a login. Before showing anything private, connect it to an account: from the website, while signed in, generate a one-time code or deep link that expires quickly. The bot receives it and stores the link. That lets customers unlink at any time, and lets you revoke access from your own admin screens. On the platform mentioned above, login uses OTP, and staff roles stay on the admin side.

Treat the bot’s API access as you would a mobile app’s. Each request acts on behalf of a particular customer, so your existing policies apply and a bug in the bot layer can’t reach another customer’s data. Keep sensitive answers short too, because chat history stays on the customer’s phone.

Notifications are often the main reason for a bot, and they have limits. According to Telegram’s FAQ, avoid sending more than one message per second to a chat, bots are limited to 20 messages a minute in a group, and bulk notifications can’t exceed about 30 messages a second without paid broadcasts. Sustained excess returns 429 errors. Send through a rate-limited queue, respect the retry time, and record each customer’s delivery status. Customers who block the bot produce errors, so stop sending to them and don’t retry forever.

Give people a way to choose which notifications they receive. A bot that sends too much will get blocked, and you lose the channel.

1. Find the three questions your support team gets most often that your API can already answer.
2. Build account linking and those three questions, with buttons.
3. Add a “talk to a person” route to a human, since a bot that traps people does more harm than none.
4. Add notifications, with opt-outs.
5. Watch what people type that the bot can’t answer. That is your backlog.

If your API isn’t ready for this, that is the real project. Our integration services page explains how we would approach it.