Send Form Submissions to Telegram (Without Leaking Your Bot Token)

Something server-side has to hold the bot token. That is the whole problem, and every working solution is some version of solving it. A Telegram bot token goes in the request URL, so calling the Bot API from your page's JavaScript publishes it to anyone who opens devtools — and a bot token is not a restricted key, it is full control of the bot.

Full disclosure: ShipMyForm is our product, and route A below uses it. Route B is free and works with any backend, including none of ours.

The mistake almost every tutorial makes

Search for this and most of the results will show you something like:

// Do not do this.
fetch(`https://api.telegram.org/bot${TOKEN}/sendMessage`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ chat_id: CHAT_ID, text: message }),
});

It works, which is why it spreads. It also means TOKEN is in your bundle, in your page source, and in the network tab of every person who ever visits. On a static site there is nowhere to hide it: environment variables at build time are inlined into the output, so process.env.TELEGRAM_TOKEN ends up in the JavaScript just the same.

What someone can do with a found token is worth being specific about, because "leaked credential" is vague enough to ignore:

• Read every message your bot can see
• Post as your bot into every chat and channel it belongs to
• Remove it from those chats, or change its name and description
• Keep doing all of that until you notice and revoke with @BotFather

Unlike some APIs there is no public-safe variant of the credential. One token, full control.

The two routes at a glance

Finding the chat ID (the step everyone gets stuck on)

Both routes need a chat ID, and it is not shown anywhere in the Telegram interface.

1. Create a bot: message @BotFather, send /newbot, follow the prompts. It gives you a token shaped like 123456789:ABCdef….
2. Send at least one message in the destination chat. If it is a group or channel, add the bot first, then post something.
3. Open this in a browser, with your real token: https://api.telegram.org/bot<YOUR_TOKEN>/getUpdates
4. Read result[].message.chat.id from the JSON.

The number's shape tells you what you are looking at:

Keep the minus sign and the -100 prefix exactly as they appear. Dropping them is the most common reason a correct-looking setup silently posts nowhere.

If getUpdates returns an empty result, the bot has not seen a message yet. Bots run with privacy mode on and only receive messages that mention or reply to them, so post something that mentions your bot, or turn privacy off with /setprivacy in @BotFather. (For sending notifications privacy mode is irrelevant — the bot only posts.)

Route A: the Telegram connector

1. Point your form at ShipMyForm:

<form action="https://shipmyform.com/f/YOUR_FORM_ID" method="POST">
  <input name="email" type="email" required />
  <textarea name="message" required></textarea>
  <button type="submit">Send</button>
</form>

2. In your form's Connectors tab, add Telegram, and paste the bot token and chat ID. The token is stored encrypted and is never sent to the browser.

3. Hit Send test. If it does not arrive, it is almost always the chat ID: check the minus sign, and check the bot is actually in the chat.

Each submission arrives as a plain message with the form name and every submitted field.

Route B: free, via the webhook connector

The webhook connector is on the free plan, so this costs nothing beyond wherever you run the function. The shape is: ShipMyForm posts the submission to your function, your function holds the token and calls Telegram.

// A Cloudflare Worker, Vercel function, or anything that runs server-side.
export default {
  async fetch(request, env) {
    const submission = await request.json();

    const lines = Object.entries(submission.data ?? {})
      .map(([k, v]) => `${k}: ${v}`)
      .join("\n");
    let text = `📝 ${submission.formName}\n\n${lines}`;

    // Telegram rejects anything over 4096 characters with a 400 rather than
    // trimming it, so an untruncated long submission fails to deliver at all.
    if (text.length > 4096) text = text.slice(0, 4060) + "\n\n… truncated";

    await fetch(`https://api.telegram.org/bot${env.TELEGRAM_TOKEN}/sendMessage`, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        chat_id: env.TELEGRAM_CHAT_ID,
        text,
        disable_web_page_preview: true,
      }),
    });

    return new Response("ok");
  },
};

Set TELEGRAM_TOKEN and TELEGRAM_CHAT_ID as secrets in your host, add the Webhook connector in ShipMyForm, and point it at the function's URL.

Two things worth doing in a real version: verify the request actually came from your form backend before acting on it, and return a non-2xx status on failure so delivery retries rather than being recorded as a success.

The limits that bite

4,096 characters per message. The one that catches people out, because Telegram returns 400 Bad Request: message is too long rather than trimming. A single long submission then fails to deliver and you get nothing at all. Truncate before sending — the snippet above does, and our connector does too, with a note so a clipped message is not mistaken for a short one.

Markdown parsing is opt-in, and strict. The examples here send plain text deliberately. If you set parse_mode: "MarkdownV2", Telegram requires a long list of characters to be escaped, and a stray . or - in someone's message fails the whole send. Plain text has no such failure mode.

Rate limits. Roughly 30 messages a second overall and about 20 per minute to a single group. Fine for form notifications; worth knowing if you ever fan out to many chats.

Which should you use?

Route A if you want it working in two minutes and you are paying for a backend anyway. The token sits encrypted, deliveries are retried and logged, and there is nothing to maintain.

Route B if you are on the free plan, want a custom message layout, or would rather hold the credential yourself. It is one small function and it is genuinely free.

What neither should be is the token in your page source. If you take one thing from this: the credential belongs somewhere a visitor cannot read, and that is the only part that is not negotiable.

Related: sending submissions to Discord, to Slack, and what a form backend actually is.