Behaviour that bridges Sexy with your application.

Implement this module to provide two things:

1. Persistence — tell Sexy which message is currently active and save new ones
2. Dispatch — handle incoming Telegram updates (commands, queries, messages)

Example implementation

defmodule MyApp.Session do
  @behaviour Sexy.Bot.Session

  # ── Persistence ──
  @impl true
  def get_message_id(chat_id) do
    case MyApp.Repo.get_by(MyApp.User, chat_id: chat_id) do
      nil -> nil
      user -> user.message_id
    end
  end

  @impl true
  def on_message_sent(chat_id, message_id, _type, update_data) do
    user = MyApp.Repo.get_by!(MyApp.User, chat_id: chat_id)
    MyApp.Repo.update!(Ecto.Changeset.change(user, %{
      message_id: message_id,
      screen: Map.get(update_data, :screen)
    }))
  end

  # ── Dispatch ──
  @impl true
  def handle_command(update) do
    {cmd, query} = Sexy.Utils.Bot.parse_comand_and_query(update.message.text)
    case cmd do
      "start" -> MyApp.Screens.home(update)
      "help"  -> MyApp.Screens.help(update)
      _       -> :ok
    end
  end

  @impl true
  def handle_query(update) do
    {cmd, query} = Sexy.Utils.Bot.parse_comand_and_query(update.callback_query.data)
    case cmd do
      "buy"  -> MyApp.Screens.buy(update, query)
      "back" -> MyApp.Screens.home(update)
      _      -> :ok
    end
  end

  @impl true
  def handle_message(update), do: :ok

  @impl true
  def handle_chat_member(update), do: :ok
end

Persistence callbacks

Sexy calls get_message_id/1 before sending to find the old message to delete, and on_message_sent/4 after sending to save the new one. Your implementation decides where state lives (database, ETS, Agent, etc.).

Dispatch callbacks

The Sexy.Bot.Poller routes every Telegram update to one of these callbacks. Each callback receives the full Telegram update map with atom keys.

Optional callbacks

• handle_poll/1 — for poll answer updates
• handle_transit/3 — for built-in /_transit navigation buttons (see Sexy.Bot.Notification)
• handle_pre_checkout/1 — for payment pre-checkout queries (auto-approved if not implemented)
• handle_successful_payment/1 — for successful payment notifications (logged if not implemented)