Email is forgiving. A webhook from a messaging platform is not. Here is what actually differs when you put Telegram, LINE, WeChat, WhatsApp and a website widget behind one inbox.
1. Each platform answers "did it arrive?" differently
Email has bounces. WhatsApp has receipts. LINE has its own delivery semantics. Telegram tells you the message was sent to the Bot API and nothing more. The website widget has no delivery state at all — a successful HTTP response is the whole story.
Modelling one status enum across all of them produces a field that means nothing. Keep the provider's native state and a small normalised enum used only to decide whether the UI may say "delivered".
2. Retries are guaranteed, ordering is not
Webhooks retry on timeout. Mobile clients queue and flush. A conversation arriving from a device that was offline will not be in timestamp order, and it will not arrive once.
Two things make this survivable: an idempotency key taken from the provider on every inbound event, and an ordering key stored alongside the message so the UI sorts on provider sequence rather than arrival time.
3. Identity is the hard part, not transport
The same person writes on WhatsApp, then emails, then opens the widget. Three identities, one human.
Resolve identity on ingest (same phone, same verified email), not on read. The cost is a merge operation when two channel identities turn out to be the same person later — which is testable — instead of reconciling three histories at query time, which is not.
4. Media is a liability, not a feature
Attachments arrive as either a URL with an expiry, a base64 blob, or a provider-hosted id that needs a second call. All three need to be mirrored into your own storage on ingest, with size limits and type checks, or your inbox breaks silently six months later when the provider rotates its CDN.
5. Rate limits shape the UI
Some platforms cap outbound messages per second per account. If the composer does not know that, an agent replying to a burst gets a silent failure. Surface the queue depth per channel, not a global spinner.
6. What we deliberately did not build
No workflow builder, no plugin marketplace. Six channels, one queue, three triage primitives (tags, priority, views), and AI drafts that live inside the conversation so a human can take over mid-thread.
The product this went into is Onsites AI — a shared inbox across website chat, email, Telegram, WhatsApp, Messenger, LINE and WeChat, with CRM and invoicing attached, free for the first three seats.
Top comments (0)