Receive data from any service in your Telegram bot
Pick your case
Open the one that matches you — four steps and you are done. The details below are optional reading.
I have a payment provider — I want the bot to write after a paymentThis is you if payments are handled by an outside service, not by Telegram.
- Create a receiverReceiving data → “Create receiver” → the “A payment service reports a payment” card. The rules fill themselves in; you type nothing.
- Check it against your own sampleTake a sample request from your provider's docs and paste it into “Sample request from your partner”. Right below it you will see order_id → A-1001. If a field says “not found”, change the field name to the one your provider actually sends.
- Give the address to your providerCopy the address and paste it into your provider's settings — the field is usually called “webhook”, “notification URL” or “callback”. The address is shown once, so copy it right away.
- Connect it to a flowPick a bot and the flow that should start. Or place a “Wait for data” block in your flow — then the bot waits for this exact payment and continues from where it stopped.
I have a form on my website — I want to continue the conversation in the botThis is you if a person fills in a form on your site and the bot talks to them afterwards.
- Create a receiverReceiving data → “Create receiver” → the “A form on your website” card. Name, phone and email fill themselves in.
- Add the person's Telegram id to the formThis is the one hard requirement: the bot must know WHO to write to. Usually the person reaches your site from a bot link, and you put their id into a hidden form field.
- Send the form to our addressSet the receiver address as the form's submit target. If a website builder makes your form, that field is called “where to send” or “webhook”.
- Pick a welcome flowConnect the receiver to a bot and a flow. Form submitted — the bot writes immediately.
I have my own program, or nothing above fitsThis is you if the event comes from something of your own — a script, a CRM, a warehouse system.
- Create a receiverReceiving data → “Create receiver” → the “My own service” card. Nothing is filled in — you set it up your way.
- Paste a sample of your own requestCopy one real request your program sends into “Sample request from your partner”.
- Add rules one at a timeA rule means “take this value and remember it under a clear name”. Add a rule and you immediately see below it what it pulled out of your sample. Guessed wrong — fix it.
- Connect it to a flowPick a bot and a flow. Values from the request arrive in the flow as variables — you can put them straight into messages.
Four reasons it usually does not work
The partner sent something but there are no events
Open the “Incoming” tab. If events are there, the receiver works and the problem is in the flow. If there are no events at all, the partner is sending to a different address: check that you pasted the address in full, including the long part after /in/.
There is an event but no variables
That means the parse rules found no values. Open the event in the log — it shows exactly what the partner sent and what each rule pulled out. Copy the real field name from there into your rule.
The log says “nobody to handle it”
The receiver has no bot or flow attached, or the flow is not published. Another option: the “how to find the person” template points at a value the event does not contain, so the bot does not know who to write to.
The customer got two identical messages
The partner sent the event twice. Turn on duplicate filtering and set a duplicate key — for example the order number plus the status. Then the second identical event will not be processed.
What happens between the partner and the bot
Optional reading — this is for people who want to understand the mechanics.
A receiver is an address
Each receiver is a separate address for one partner. Separate, so you can switch one off without breaking the others, and so the log shows who exactly sent what.
We accept the event and answer immediately
The partner gets an “accepted” response within milliseconds while processing continues on its own. That way the partner does not treat delivery as failed just because your flow is thinking.
Rules pull out the values
Only the values you named are taken from the request. They become flow variables — you can put them in a message or compare them in a condition.
The event takes one of two paths
Either it resumes a flow that was parked on a “Wait for data” block waiting for this exact event, or it starts a flow from the beginning. The first path is for “payment for this specific order”, the second for “something new arrived”.
Six places in a request you can take a value from
Nine times out of ten you need the first three. The rest are for rare cases, but they exist and they are not hidden.
| Where to take it from | What exactly to take |
|---|---|
| JSON fieldCommon — this is how almost everyone sends data | How almost every service sends data. Pick this one if unsure.Partner sent {"order_id": "A-1"} → type order_id |
| Form fieldCommon — this is how almost everyone sends data | If the partner posts data like a plain web form.Partner sent order_id=A-1&status=paid → type order_id |
| Query parameterCommon — this is how almost everyone sends data | The data sits right in the link, after the question mark.The address ends with ?status=paid → type status |
| HeaderAdvanced — rarely needed | A technical request line — for example X-Event-Type.The request has a line X-Event-Type: payment → type X-Event-Type |
| Pattern over textAdvanced — rarely needed | Find a piece of text by a pattern — when plain fields do not fit.The text says Payment A-1 completed → type Payment (\S+) |
| Whole bodyAdvanced — rarely needed | Take the whole request text as it arrived.The entire request text goes into the variable as it arrived |
So that nobody can pose as your partner
Three ways to verify the sender
From “knowing the address is enough” to verifying a signature made with a shared key. Your partner dictates which one — you pick what they support. The key is stored encrypted and is never shown again.
The address can be changed in one click
If the address leaked, you change it and the old one dies immediately. All that is left is pasting the new one into your partner's settings.
Limits and request size
A request that is too large is rejected before parsing. A flood from one partner is rate-limited so it cannot disturb your other receivers.
A log of every event
Every event is visible in full: what arrived, what the rules pulled out, what happened to it and why. Passwords and technical headers are never written to the log.
Frequently asked questions
What does receiving data in a Telegram bot mean?
It is a way to give an outside program an address where it reports events: a payment went through, a form was filled in, an order status changed. Your bot receives that event and reacts according to your flow, on its own.
Is this the same as a webhook?
Yes. “Webhook” is the technical name for an address an outside service posts event notifications to. We call it a receiver so it makes sense without a glossary.
Do I need to know how to program?
No. You pick who sends you data, paste a sample of their request and see what gets pulled out of it. Not a single line of code.
Which services does this work with?
Any service that can send a request to a given address. Almost every payment provider, website builder, CRM and warehouse system can.
How do I make the bot wait for a payment and then continue?
Place a “Wait for data” block in your flow and set a wait key — the order number, for example. The flow stops, and when an event with the same number arrives it continues from that point.
What happens if the payment arrives too late?
The wait has a deadline. If the event arrives after it, the flow will not resume — but the event is not lost: it lands in the log, and if the receiver has a handler flow it starts that flow from the beginning.
My partner sends one event twice — what do I do?
Turn on duplicate filtering and set a duplicate key from the event's own values, for example the order number plus the status. Events identical by that key will not be processed a second time.
Could someone send an event pretending to be my partner?
To rule that out there is sender verification: an agreed secret, or a signature over the request body made with a shared key. Pick whichever your partner supports and foreign requests get rejected.
Can I check it without connecting the partner?
Yes, in two ways. The live preview shows what the rules pull out of a pasted sample and sends nothing anywhere. The “Test request” button sends an event to yourself through the real pipeline, which checks the whole chain up to the flow.
How many receivers can I create?
As many as your plan allows. Usually one receiver per partner — that makes them easier to switch off individually and shows who sent what.
Launch your Telegram bot with Forgebot
Build your first flow, reply to subscribers and watch analytics — free, no code.
Free plan: 1 bot, 5 flows, 100 subscribers. No card required.