---
title: "Post Leave"
method: POST
path: "/api/channels/meet/sessions/{session_id}/leave"
tags: ["channels", "channels", "meet-voice"]
---

# Post Leave

`POST /api/channels/meet/sessions/{session_id}/leave`

## Request

- Base URL: `https://api.dialogbrain.com` (the document declares no server; this is the origin it was published from)
- URL: `https://api.dialogbrain.com/api/channels/meet/sessions/{session_id}/leave`
- Auth: none declared

Signal meet-bot to leave the meeting.

Publishes `leave_call` on the session's voice-event stream — the SAME
signal `MeetVoiceAdapter.hangup_remote` sends, and the reason this is not
the Redis list it used to be.

The list (`meet_bot:leave:<id>`) was read by one loop in the bot, started
after the join phase. A bot that has not joined yet is not idle: Google
rejects an automated join, and the bot then HOLDS at pre-join for up to
twenty minutes so an operator can carry it in by hand through noVNC.
Nothing read that list during the hold. So this endpoint answered 200 and
did nothing, for exactly as long as the hold lasted — six sessions stayed
`active` with live containers and heartbeats after being asked to leave
(2026-08-31).

`leave_call` is watched in BOTH phases: `_hold_for_manual_join` takes the
same event (added when Cancel had this bug and was fixed for that button
only), and the post-join loop races it. One signal, honoured wherever the
bot happens to be.

## Path parameters

- `session_id` string, required: Session ID

## Request body

- PostLeaveRequest: Request to leave a Google Meet.

## Response `200`

Successful Response

- unknown

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/dialogbrain/apis/dialogbrain-v2-api-gateway.md) · [All operations](https://skmtc.dev/dialogbrain/apis/dialogbrain-v2-api-gateway/llms.txt) · [OpenAPI document](https://skmtc.dev/dialogbrain/apis/dialogbrain-v2-api-gateway/revisions/d84e7dc9977d?raw)