Common integration patterns and use cases
Design offline handling around automatic SDK behavior. The Web SDK buffers for 15 seconds, continues recording locally, and uploads after reconnect. Your application should surface status and expect delayed submission. The following patterns show common ways to work with offline ambient in the Web SDK:Show Connection Status During the Buffer
Use the 15-second buffer window to display a connection status message in your host UI before the session enters full offline mode.
Keep Recording During Network Loss
Let the SDK continue capturing audio locally when the network drops. Do not treat a brief disconnect as a failed ambient session.
Expect Paused Submission Until Reconnect
Treat offline sessions as not yet submittable. The SDK pauses submission and retries upload and note submit after connectivity returns.
Plan for Slower Note Generation After Offline
After reconnect, expect longer note generation because the full audio must upload first. Keep your note-submission handlers ready for delayed delivery.
What triggers offline mode
A session enters offline mode due to:- Network interruptions
- Backend unavailability
- High latency in audio transmission
- Socket connection drops
- Authentication failures
Offline mode behavior
When the session enters offline mode, the SDK automatically:Continues Recording
Audio recording continues without interruption during network issues.
Local Storage
Audio and metadata are stored locally on the device.
Automatic Upload
Stored data is automatically uploaded once connection is restored.
User Notification
Users are notified about offline status and reconnection attempts.
During offline mode, session submission is temporarily paused. The SDK will continuously attempt to reconnect and submit the note once connectivity is reestablished.