Omi audio bridge

The Omi bridge receives Omi's Realtime audio bytes webhook and saves it to a separate Optima Source named Omi. It uses stock Omi firmware and the Omi app. No Mac companion, local server, or custom firmware is required.

Connect your accountsCopy Anchor Link

1. Open omi.hnf.dev and sign into your Optima account with the six-digit email code.
2. Copy your private audio link.
3. In Omi, open Settings → Developer Mode → Realtime audio bytes. Enable the webhook, paste the link, and choose a 10-second interval.
4. Start live listening in Omi. The page shows when audio arrives and when Optima confirms receipt. Your Omi Source appears when the first upload starts.

You can close the page after setup. Omi's live-listen session must remain active. This connection uses a private webhook link rather than an Omi OAuth sign-in. Historical and offline recordings are not imported.

Account and credential boundariesCopy Anchor Link

Each Optima account has one Omi connection and a stable source identity. Reconnecting preserves that Source; you can rename it through Optima's normal source controls. The source's API kind is web because it is managed by the hosted bridge.

The bridge holds its own Optima session server-side and refreshes it when needed. The browser receives an HttpOnly management cookie, never Optima access or refresh tokens. Signing out of the page invalidates that cookie and leaves audio forwarding running. Disconnect Omi disables intake and uploading; sign in again to resume. Pending audio remains with the same account.

The private URL is an intake credential. Anyone holding it can submit audio to this connection. The first accepted delivery binds the Omi uid; that value never chooses an Optima account. Replace private link revokes the previous URL. Copy the replacement into Omi. Replacing a link does not change the bound Omi identity.

Audio custody and limitationsCopy Anchor Link

The bridge durably stores PCM before acknowledging a webhook. Omi can split a configured interval into one-second deliveries. The bridge combines these in receipt order into roughly one-minute PCM16 WAV chunks, preserving the exact samples, and follows the audio upload flow. It flushes a shorter final chunk after 30 seconds without new deliveries. A delivery stays intact, so a chunk can exceed one minute when a larger delivery crosses the target. It releases queued bytes only after matching Optima's confirmed size and SHA-256. A successful upload does not guarantee successful transcription.

Omi sends mono, little-endian PCM16 at 8 or 16 kHz. The bridge accepts up to 60 seconds per delivery. Each account's pending queue is bounded to 512 deliveries and 64 MiB; when full, new deliveries receive 503. Failed uploads retry in the background. The page reports pending deliveries and sign-in problems.

Requests with Idempotency-Key are deduplicated through seven days after confirmation. Requests without it cannot be reliably deduplicated. Consecutive chunks share a recording stream and advance by sample count, giving transcription longer passages instead of separate one-second recordings. A receipt gap of 30 seconds, a sample-rate change, or disconnecting starts a new recording.

Omi supplies no capture timestamp or reliable sequence counter. The bridge estimates captured_at from the first delivery's receipt time minus its PCM duration, then uses cumulative sample offsets. Turns use that anchor plus their offsets, so both audio and turns appear in dated timeline views. Retries preserve the estimate and the exact sealed chunk. Receipt order and inferred recording boundaries do not prove gap-free capture. Network and forwarding delays can shift the estimate; clock_uncertainty_ms is null because their bound is unknown.

Connection settings and pending audio use Cloudflare Durable Object storage. Uploaded audio, Sources, and processing use Optima's existing storage and data model; there are no additional Supabase tables for Omi.

See Omi's streaming guide for settings and integration guide for live-listen delivery limits.