Awaiting asynchronous operations
The model
A 202 Accepted Operation means authentication, authorization,
schema, and basic validation passed and the command entered the processing queue.
A failure before that point is a synchronous HTTP error.
Processing may then emit a success event, a failure event, or multiple lifecycle events.
They normally share the command’s operation_uuid. recording.ended carries
the originating recording/start UUID, including when a later stop command
caused the event.
Generate that UUID yourself, install a listener, and only then send the command.
This gives application code a normal await:
A small Node.js wrapper
Call handleOperationEvent only after verifying and deduplicating the webhook.
The listener is registered before dispatch, so a fast event cannot be missed.
Non-terminal events are ignored until an event listed in resolveOn or
rejectOn arrives.
Keep in mind
- Choose terminal events from the command’s API reference and the relevant webhook reference. Not every command has one, and a local timeout does not cancel remote processing.
operation_uuidcorrelates events. UseIdempotency-Keyseparately to make supported command retries safe.- This in-memory example assumes one process. Multi-instance applications need shared event routing.
Planned official SDKs will provide this clean await API without requiring you
to implement correlation, listeners, timeouts, or typed results yourself.