How to Stop a Meeting Bot Mid-Meeting — and Why It Matters

Why you'd stop a bot early

Bots that automatically leave when the meeting ends work for most cases. But there are scenarios where you need to eject the bot early:

• The meeting started late and you only need to capture the second half
• A sensitive topic comes up and the host wants the recorder off
• Your application logic determines the relevant portion of the meeting is over
• A user in your product pauses or stops their recording

In all of these cases, waiting for the meeting to end naturally means capturing and billing for audio you don't want.

The stop endpoint

curl -X POST https://api.gregnote.com/v1/bots/{botId}/stop \
  -H "Authorization: Bearer gk_live_YOUR_KEY"

The bot leaves the meeting immediately. The full pipeline — transcript finalisation, webhook delivery, billing — runs on the audio captured up to that point. You receive a meeting.completed webhook within seconds of calling stop.

In your application

async function stopRecording(botId) {
  await fetch(`https://api.gregnote.com/v1/bots/${botId}/stop`, {
    method: "POST",
    headers: { Authorization: `Bearer ${process.env.GREGNOTE_KEY}` },
  });
  // The meeting.completed webhook will arrive in seconds
}

Expose this as a button in your UI so users can stop their recording on demand.

What happens without a stop call

Without an explicit stop, the bot waits up to 60 seconds of silence after all other participants leave before completing. This handles the case where participants temporarily drop off — the bot doesn't eject at the first sign of silence.

If meeting participants leave all at once but your server crashes before the meeting.completed webhook is processed, the transcript is still delivered when your server comes back up — webhook retries at 1m, 5m, 30m, and 2h handle this automatically.