Re-register the webhook after Telegram drops it
Fix a stalled bot when the panel shows no recent /start.
Telegram occasionally drops a bot's webhook subscription — after an infra change on their side,
after a long period of inactivity, or after something else quietly called setWebhook/
deleteWebhook on your bot's token. When that happens the bot stops receiving /start entirely,
with no error on your side to notice it by — the fix is to tell Telegram to point back at your
webhook.
When to use this
The bot card's status line is the signal: a green running dot with a last update time that keeps growing (or reads "no updates yet" for longer than expected) means Telegram isn't delivering. An amber webhook not set status means the last registration attempt itself didn't stick.
Re-register
curl -X POST https://app.tease.link/api/admin/tg/gate/webhook/refresh \
-H "Authorization: Bearer $TEASE_API_KEY"In the panel this is the small webhook button next to the status dot (a refresh icon). It
re-runs setWebhook with this bot's own secret token against the configured public host — no
token re-entry needed, and your settings are untouched.
If no bot is connected yet at all, this call has nothing to refresh — connect one first. See Connect your own turnstile bot.
How to know it worked
A successful call updates the bot card's webhook set_at timestamp immediately. Send /start
to the bot from Telegram — a reply within a couple of seconds means the webhook is live again;
the last update time on the card should also refresh once Telegram's request lands.
If it didn't work
400 webhook_host_not_configured— the backend has no public webhook host set; this is infra-side, not something to fix by retrying.409 connect a bot first— no bot/token to register a webhook for.502 telegram_unreachable— a network fault reaching Telegram; retry.502 setwebhook_failed— Telegram itself rejected the registration (unlikely with a previously-working bot); double check the bot's token is still valid in @BotFather and hasn't been revoked.
This refresh exists specifically so a failure here is loud (502, not a silent no-op) — a
webhook that silently stays broken is worse than one that visibly fails to re-register.
What's next
- Still nothing after a successful refresh? See Troubleshooting for the deeper webhook auth failure modes (503 vs. 403).