The path handle_health answers on by default.

Default maximum size in bytes for the incoming webhook request body.

Telegram updates are small, so 4MB is plenty while keeping a sane upper bound. Use handle_bot_with_limit to override it.

A handler to process incoming requests from the Telegram API directly on top of mist, without wisp — for minimalistic deployments.

It checks the webhook path, validates the secret token, decodes the incoming update, and dispatches it to the bot in a separate process so the 200 OK response is returned immediately (Telegram waits for the response before sending the next update).

import gleam/http/request.{type Request}
import gleam/http/response.{type Response}
import mist.{type Connection, type ResponseData}
import telega.{type Telega}
import telega_mist

fn handle_request(
  req: Request(Connection),
  bot: Telega(session, error, dependencies),
) -> Response(ResponseData) {
  use <- telega_mist.handle_bot(telega: bot, req:)

  // Your other routes here...
  response.new(404) |> response.set_body(mist.Bytes(bytes_tree.new()))
}

Same as handle_bot, but lets you set the maximum request body size in bytes.

Like handle_bot, but lets the handler answer the update directly in the webhook HTTP response body (webhook reply), saving one HTTP round-trip for the first eligible API call.

Unlike handle_bot, the request process waits up to timeout ms for the handler to either claim a reply or finish; after the timeout it answers an empty 200 OK and the handler keeps running in the background. Pick a timeout safely below Telegram’s webhook timeout — e.g. 5000 ms.

⚠️ A claimed call resolves to a synthetic stub inside the handler (True for boolean methods, a fake Message for sendMessage). Full guide in telega’s telega/webhook_reply module docs.

Same as handle_bot_with_reply, but lets you set the maximum request body size in bytes.

Answer a health probe on path (no leading slash), and let every other request through to next.

GET /healthz answers 200 with {"status":"healthy","in_flight":3,"chat_instances":41} while the bot actor is alive, accepting updates, and below the cap set by telega.with_max_in_flight; 503 with the same shape (draining, overloaded, unavailable) otherwise. That is what a load balancer, a Kubernetes readiness probe or a fly.io health check wants: a deploy drains out of rotation instead of black-holing updates.

fn handle_request(req: Request(Connection), bot: Telega(s, e, d)) {
  use <- telega_mist.handle_health(telega: bot, req:, path: telega_mist.default_health_path)
  use <- telega_mist.handle_bot(telega: bot, req:)
  response.new(404) |> response.set_body(mist.Bytes(bytes_tree.new()))
}