Define a contract for one event
- Input: event type, identifier, user, an agreed minimum of fields and receipt time.
- Action: check access, find previously processed events and save inquiry state.
- Output: inquiry identifier, external-exchange status and a clear user response.
- Failure: an owner for retries and recovery, plus diagnostic retention without unnecessary personal data.
Choose one way to receive events
getUpdates and webhooks are alternative update-delivery methods. Telegram sends HTTPS POST requests to a webhook; update_id helps distinguish repeated events. Choose around the environment and operating model, rather than a programming-language name.
When using secret_token, validate its incoming header. Keep the bot token and secrets server-side, outside public pages and logs. Agree who owns the bot, handler address and environment access.
Official source: Telegram Bot API: receiving updates
Test repeats and external failures
In the hypothetical scenario, an event with the same identifier should return its saved result. A separate user request needs its own business identifier: matching text does not always mean duplication. With asynchronous handling, durably save the event before external exchange.
If the CRM does not respond, do not announce that the CRM inquiry was created. Record an uncertain status, check the outcome by identifier, then decide whether to retry. HTTP acknowledgement does not prove the entire business process finished or a person received the reply.
Do not trust the Mini App browser
Validate initData server-side using Telegram’s official procedure before using it. initDataUnsafe is not verified user identity. After validation, apply your own permissions separately: authentication does not grant access to another person’s inquiries.
Determine totals, order status and record ownership from server data. Restrict user fields to an agreed format. An API response or payment screen does not prove actual payment; confirmation must come from the agreed source.
Official source: Telegram Mini Apps: data validation
Accept launch through five scenarios
- A valid new inquiry: one record is saved, with a verifiable reference and state.
- A repeated event: no extra inquiry or unwanted second notification.
- An external failure: visible status, an assigned owner and an agreed retry route.
- Another user’s record or invalid input: access is denied, the error is clear and no secret is exposed.
- A handler restart: saved inquiries and processing state remain available; the team knows the recovery procedure.
Discuss your project
Tell us your goal, languages and required functions. We will agree on the scope and next steps.