Skip to main content

​
Inbound AI enrichment

Inbound AI enrichment is the detect-then-translate pass every inbound message can run after Orbit has resolved ownership and routed the conversation. One helper detects the message body’s source language, auto-translates non-English bodies into English, and persists the results onto the message’s metadata, where the inbox, routing rules, and the voice gateway read them. This page explains that pass end to end: where it sits in the pipeline, the exact metadata keys it writes, the minimum-length short-circuit, which channels participate, and the tenant setting that switches it off.

​
Where it runs in the pipeline

The inbound pipeline resolves before it enriches. Tenant ownership is settled first — inbound message resolution decides which tenant receives an inbound message or delivery receipt, and the tenant-level rule engine layers keyword, language, and queue distribution on top of that. The enrichment pass runs after the message is stored and acknowledged (at the router level): it is deliberately fire-and-forget, so the sender’s webhook acknowledgment never waits on a language-model round-trip, and a failing enrichment never blocks or drops the message. Because the write lands after the initial store, enrichment also signals the inbox a second time: when the metadata update lands, Orbit pushes a real-time refresh to any agent with the thread open, so the detected language and translation appear live instead of on the next poll. If that push fails — a realtime outage — the enrichment result is still persisted; it simply surfaces on the inbox’s normal poll cadence. The language condition in inbox routing rules consumes the detected language this pass produces — and the dry-run panel on a routing rule shows the same detector’s read on a sample body before the rule goes live.

​
The two outputs on message metadata

Every enrichment result lands on the message’s metadata as plain key-value entries you can read through the API, webhooks, or the dashboard:
  • detected_language — the ISO 639-1 code the detector read from the body (for example tr, es, or en).
  • detected_locale — a mirror of detected_language, written in the same pass so both keys stay in sync. New consumers can adopt detected_locale without dual-reading the older key; existing consumers keep using detected_language.
  • translation_en — the English translation of a non-English body. This powers the per-message Show translation affordance in the inbox, where an agent toggles between the original body and the English rendering.
English bodies get a lighter result: detected_language and detected_locale are recorded as en — so consumers can distinguish “checked, was English” from “never checked” — and no translation_en is written, because English is the operator-inbox-native language. When detection cannot name a language with confidence, nothing is recorded at all; a longer follow-up message from the same conversation is a fresh chance to enrich.

​
The 20-character short-circuit

Bodies up to 20 characters long skip the language-model round-trip entirely. The rationale: short bodies — “ok”, ”👍”, “yes” — are not worth confident detection, and the model rarely identifies the source language reliably on that little signal. The threshold is 20 characters, shared by design with the WhatsApp AI pipeline’s historical minimum, so traffic that previously funneled through that pipeline sees identical short-circuit behavior. Practical consequence: expect the first substantive message in a conversation to be the one that carries language metadata. Tactical replies under the threshold simply inherit the conversation’s already-detected context.

​
Channel coverage

The enrichment pass is channel-agnostic. It was originally WhatsApp-only, embedded in the WhatsApp AI ingestion pipeline; it has since been extracted into a shared helper that every inbound ingest path calls after inserting the message and before acknowledging the sender. Channels that funnel through the generic inbound ingestion carry it: WhatsApp, SMS, email, RCS, Viber, LINE, Telegram, Messenger, Instagram, and fax. The native web-chat widget inbound path — the surface that bypassed the generic ingestion — now calls the same helper directly, closing the last gap.

​
The tenant gate

Enrichment is tenant-controlled. Under Organization settings the inbox-AI translation toggle switches the pass off for your workspace: when disabled, enrichment short-circuits before any language-model round-trip or metadata write — message bodies are never sent to a model provider for translation. The default is on. A failure to read your settings is fail-open: a settings outage cannot silently disable translation across workspaces. Consumers read the metadata, never the display text. The inbox’s Show translation toggle, the routing-rule language condition, and the voice gateway all key off detected_language / translation_en on the stored message — so gating enrichment off starves every consumer of new values at once, while existing metadata on older messages remains readable.

​
See also