Reliability and recovery

Replay and retry are different

• Replay means you never received the response. Send the same completion command with the same Idempotency-Key; Revero returns the same operation.
• Retry means the operation reached failed and its typed failure says retryable: true. Send completion again with a new key. You do not need to upload the audio again.

A new key while work is still outstanding returns 409. A new key after a non-retryable failure also returns 409.

Bound every poll

Use the SDK polling helper with an application deadline. It observes Retry-After when Revero returns 429 and bounds exponential backoff for other non-terminal responses. A timeout is an uncertain observation, not evidence that processing failed: retain the operation id and read it again later.

Treat reads as authoritative

Webhook delivery is at-least-once and unordered. Deduplicate on event id, then read the linked meeting or operation. A dropped webhook costs one later read; it does not change operation state or lose an output.

transcription_empty means we could not hear it

Not that the file was silent, and not that the transcript was zero bytes. A recording made at too low a level can come back from a speech model as fluent, grammatical, confident-looking prose that has nothing to do with the audio, and the model reports its own near-zero confidence beside it. Revero refuses those rather than handing you a document, because a fabricated transcript is indistinguishable from a real one by reading it.

retryable is false and that is not a formality. The behaviour is deterministic: the same bytes produce the same invented text. Record again at a higher level and create a new meeting. If the source is a browser capture, check the input gain before assuming the audio was fine.

Preserve stable codes

Every non-token API error has a stable code and a human-oriented message. Operation failures additionally report failure_code and retryable. Branch on the codes and boolean. Log the message, but never parse it.