The meeting lifecycle and speaker naming

A meeting you send is worked on in the background: Lobbe transcribes it, may wait for the speakers’ names, then writes its Lobbe. This page follows one meeting from the 202 to READY, and covers what can stop it on the way.

The statuses

GET /recordings/{id}/status gives the meeting’s status:

status	What it means
QUEUED	Lobbe has the audio, and the meeting is waiting its turn
TRANSCRIBING	The audio is being transcribed
NAMING	The transcript is ready, and the meeting is waiting for its speakers’ names, or a skip
GENERATING	The Lobbe is being written
READY	Done: its bundle can be read
FAILED	It stopped, and error.code says why

• On its way to READY, every meeting passes through QUEUED, TRANSCRIBING and GENERATING. Only NAMING can be skipped: see Speaker naming.
• A status can also go back. A retry sends a FAILED meeting back to the step that failed. When the person regenerates the Lobbe in the app (Regenerate the Lobbe), a READY meeting is GENERATING again until the new Lobbe is ready. When they ask Lobbe to Check the meeting again from the naming sheet, it goes back to QUEUED.
• Asking once a minute, you won’t see every status. Don’t wait for one in particular: act on NAMING, READY or FAILED whenever you see it.
• Once the meeting is deleted, its status answers 404.

How often to ask, and how to follow many meetings at once, is in Polling and the events feed.

What a meeting costs

The 202 from POST /recordings carries minutes: the audio’s length, plus the vocabulary surcharge when useKeyterms applies, plus the attachment.

• From the moment Lobbe accepts the meeting, those minutes are held: the next meeting you send can’t spend them.
• They are charged once, when the transcript is ready. So a meeting that waits at NAMING, or fails while its Lobbe is being written, has already paid.
• A meeting whose transcription fails costs nothing, and neither does one deleted before its transcript is ready.
• If Lobbe can’t use the attachment in the end, its minutes are left out of the charge.

What happens when the balance runs short, and the token’s daily cap, are in Minutes, caps and limits.

Speaker naming

Why a meeting waits

When the transcript has two or more voices, Lobbe can stop at NAMING so the person names the speakers before the Lobbe is written: its decisions and action items then carry real names instead of “Speaker 1”. Whether it stops, and for how long, follows the owner’s Name speakers setting in the app:

Setting	speakerNamingMode	What happens
Ask	FORCE_ON	The meeting waits until the speakers are named or skipped, or until naming.deadline passes
Ask, but don’t wait	AUTO	It waits a short while, then goes on by itself
Auto-guess	FORCE_OFF	It never waits, and Lobbe guesses the names where it can

A meeting with a single voice can stop at NAMING for a short while too, so someone watching can still name it. Lobbe doesn’t notify the person about that one.

A token holding account:read reads the setting as settings.speakerNamingMode in GET /account.

At NAMING

The status carries naming:

"naming": {
  "url": "https://app.lobbe.ai/m/MEETING_ID?name=speakers",
  "deadline": "2026-10-20T08:45:00.000Z"
}

• naming.url opens the meeting’s naming sheet in the app, where the person listens to each voice and writes a name. It opens only for the account’s owner, signed in, so it is safe to send in a chat or an email. Opened after the meeting has moved on, it just opens the meeting.
• naming.deadline is when Lobbe goes ahead without the names. At that moment or a few minutes after it, the Lobbe is written with the names Lobbe can fill in itself (voices it recognizes, for example), and the person can still name the speakers later. How far off it is depends on the setting: a short while with Ask, but don’t wait, hours with Ask.
• naming.deadline can be null, with Ask: Lobbe then waits for the person, with no end.
• The deadline can move later when the person opens the naming sheet. Read it from the latest status rather than keeping the first one.

Skipping naming

POST /recordings/{id}/naming with { "action": "skip" } does what Skip does on the naming sheet: each voice nobody named takes Lobbe’s suggestion where it has one, and the Lobbe is written.

curl https://app.lobbe.ai/api/v1/recordings/MEETING_ID/naming \
  -H "Authorization: Bearer $LOBBE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "action": "skip" }'

• The answer is 200 with the meeting’s status, the same body as GET /recordings/{id}/status.
• A meeting that isn’t at NAMING (it has moved on, or hasn’t got there yet) answers 409 NOT_NAMING. Read its status instead of skipping again.
• skip is the only action: a token can’t write names. Naming is the person’s, through naming.url.
• Skipping costs nothing. It needs recordings:write, and it works on your own meetings, never on those of a series you joined. Without recordings:read, only on meetings this token sent.

Skipping naming at upload

To never stop at NAMING, send naming=skip with the meeting:

curl https://app.lobbe.ai/api/v1/recordings \
  -H "Authorization: Bearer $LOBBE_TOKEN" \
  -F "audio=@meeting.m4a;type=audio/mp4" \
  -F naming=skip

The meeting goes from its transcript straight to its Lobbe, and voices are named as a skip names them. Without it (naming=default), the owner’s Name speakers setting decides.

FAILED and retry

At FAILED, the status carries error:

"error": { "code": "TRANSCRIBE_FAILED", "retryable": true }

• error.code says which step failed: TRANSCRIBE_FAILED or GENERATE_FAILED. NO_SPEECH means the audio has no speech in it, and AUDIO_CORRUPT that the transcription service refused the audio as damaged.
• error.retryable says whether a retry can help. It is false for NO_SPEECH and AUDIO_CORRUPT: the same audio fails the same way again.
• FAILED can be temporary. Lobbe retries a failed step by itself, and the meeting may move on without you. The events feed sends recording.failed only once a failure is final.

POST /recordings/{id}/retry runs the failed step again (a transcript that is ready is never redone) and answers 200 with the status:

curl -X POST https://app.lobbe.ai/api/v1/recordings/MEETING_ID/retry \
  -H "Authorization: Bearer $LOBBE_TOKEN"

• A meeting that isn’t FAILED answers 409 NOT_FAILED.
• A retry costs nothing more: a meeting that failed while its Lobbe was being written has paid already, and one whose transcription failed pays only once, when its transcript is ready.
• If Lobbe is still retrying the step by itself, your retry doesn’t start a second run.
• An AUDIO_CORRUPT meeting isn’t run again: the answer is its status, still FAILED.
• A NO_SPEECH meeting is run again. Lobbe lets a few silent meetings a day fail for free; past that, a silent meeting gets an empty Lobbe and is charged. Retry one only if you know the audio has speech in it.
• Retry needs recordings:write and reaches the same meetings as a skip.

The meeting time

recordedAt is when the meeting happened. Send it with the meeting, in ISO 8601 with an offset:

curl https://app.lobbe.ai/api/v1/recordings \
  -H "Authorization: Bearer $LOBBE_TOKEN" \
  -F "audio=@meeting.m4a;type=audio/mp4" \
  -F recordedAt=2026-10-19T10:30:00+03:30

• Without it, recordedAt is the moment Lobbe receives the meeting.
• It may be up to 5 minutes in the future (clocks drift) and not before 2000. Anything else answers 400 VALIDATION.
• The app shows this time on the meeting and sorts the archive and series pages by it, so a meeting held last Tuesday and sent today sits with last Tuesday’s. Search orders by it too, and its from/to filters read it.
• createdAt is when Lobbe received the meeting. The list of finished meetings (GET /recordings/ready) and the events feed keep that order, so a meeting sent with an earlier recordedAt is never missed by a script that reads them.

Note

Sending meetings, creating and editing series, changing settings, search and Ask through a token are being switched on gradually. If the form in Connections doesn’t offer a scope, it isn’t available to your account yet.