Core concepts
Bots
Sending the notetaker into a call, and the three rules that govern it.
Most recordings happen because a calendar meeting matched a rule. This is the other way round: a call is happening now, and you want the notetaker in it.
curl -X POST https://api-notetaker.nabrah.ai/ext/v1/bots \
-H "Authorization: Bearer $NABRAH_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: 7f3c1e90-2f1a-4c0e-9a3b-9d2e5f6a7b8c" \
-d '{"joinUrl":"https://meet.google.com/abc-defg-hij","title":"Vendor call"}'Three rules, and each fails differently
In a team
One bot records a call for everyone in the same organization, and it joins as Nabrah Notetaker rather than under one person's name. A teammate's POST /bots for a call the team is already recording returns 409 with code: "TEAM_ALREADY_RECORDING", and the same call on their calendar is not recorded twice.
Nobody loses the meeting for it. Once the recording is ready, every teammate it covered gets their own copy of the notes under their own runId: it is listed by GET /recordings, can be edited and shared like any recording of theirs, and sends meeting.ready to their webhooks. Edits to one copy never change another, and the call is counted once, against the recording.
Watching it happen
POST /bots answers as soon as the bot is dispatched, not when it has joined. Poll GET /bots/{runId} to follow it, or take the webhooks and do not poll at all.
| State | Means |
|---|---|
pending · dispatched | On its way |
live | In the meeting, recording |
ended | Left the meeting; analysis has not finished |
processing | Transcribing and summarising |
ready | Notes exist — GET /recordings/{runId} |
failed | Could not join, or nothing was recorded |
Prefer webhooks
meeting.started, meeting.ended and meeting.ready tell you each transition as it happens. A bot can sit in an hour-long call; polling costs you a request a minute and tells you nothing new for most of them.
Always send an Idempotency-Key
A timeout does not tell you whether the bot was dispatched. Retrying blind is how one call ends up with two — except the second is refused by the one-bot rule, so what you actually get is a confusing 409 instead of the answer you missed.
With an Idempotency-Key, the retry returns the original response, byte for byte, with Idempotency-Replayed: true.
Stopping early
curl -X POST https://api-notetaker.nabrah.ai/ext/v1/bots/$RUN_ID/stop \
-H "Authorization: Bearer $NABRAH_API_KEY"Whatever was captured up to that point is still processed into notes — stopping is not discarding. A run that has already finished answers 404, because there is nothing left to stop.