> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Troubleshooting: LINE, Kakao, WeChat, and Zalo inbound never arrives

> The four-channel inbound matrix for APAC messaging apps — which channels push via provider-registered webhooks (LINE), which are gateway-relayed (Kakao, WeChat, Zalo), and the per-channel gates that stop a `message.received` event from ever firing.

# Troubleshooting: LINE, Kakao, WeChat, and Zalo inbound never arrives

A contact messages your APAC-brand channel and nothing surfaces: no Inbox
row, no `message.received` webhook delivery, no row you can look up. This
page is the APAC sibling of
[Troubleshooting: inbound WhatsApp or RCS message never arrives](/troubleshooting/inbound-channels-no-route) —
it covers LINE, KakaoTalk, WeChat, and Zalo, which each gate inbound
differently.

The four channels split into two distinct inbound wiring classes. Resolve the
wrong class and the runback lasts a long time:

* **LINE** — provider-registered webhook. Until you set the Webhook URL in
  the LINE Developers Console, LINE holds everything upstream. See
  [Troubleshooting: LINE inbound events never arrive](/troubleshooting/line-webhook-setup).
* **KakaoTalk, WeChat, Zalo** — gateway-relayed inbound. Orbit's messaging
  gateway normalizes and relays replies automatically; there is no provider
  console webhook for you to register. A miss here is one of
  credential-resolution, event-filtering, or subscription scope — not
  wiring.

## Symptom map — channel-specific failure modes

| Symptom variant                                      | LINE                                                                             | KakaoTalk                                                                                       | WeChat                                                    | Zalo                                  |
| ---------------------------------------------------- | -------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | --------------------------------------------------------- | ------------------------------------- |
| **Nothing inbound, first ever**                      | Console Webhook URL unset — LINE holds all events upstream                       | Gateway relay is automatic — check per-org credentials are connected so inbound has an identity | Same — check the OA is connected                          | Same — check the ZOA is connected     |
| **Inbound died after a credential rotation**         | Secret rotation breaks signature verification immediately — re-paste             | Gateway relay re-keys on the current credential — replies follow the current sender profile     | OA-reply relation survives token rotation, NOT an OA swap | Same as Kakao                         |
| **Only some event types forward**                    | Follows/postbacks/reads are acknowledged but never forward on `message.received` | Replies forward on `message.received`; status callbacks land separately                         | `TEMPLATESENDJOBFINISH` callbacks are send-side only      | Replies forward on `message.received` |
| **Inbound arrives but the automation misclassifies** | `channel: "line"` filter is semantic, not a routing miss                         | Same — filter on `data.channel`                                                                 | Same — filter on `data.channel`                           | Same — filter on `data.channel`       |

## Diagnostic steps

1. **Read the delivery log.** List webhook endpoints with
   `GET /api/v1/webhooks`, then read the endpoint's recent deliveries with
   `GET /api/v1/webhooks/{endpoint_id}/deliveries`. You want
   `message.received` with `channel: "line" | "kakao" | "wechat" | "zalo"`.
   An empty list means the event never fired (routing miss); a failed delivery
   row means your endpoint rejected it. Tooling:
   [Inspecting deliveries](/webhooks/inspecting-deliveries).
2. **For LINE only: verify the console Webhook URL.** Any result other than
   LINE holding events upstream means this page appertains further — see
   [Troubleshooting: LINE inbound never arrives](/troubleshooting/line-webhook-setup).
3. **Check the channel is resident on the organization.** A gateway-relayed
   channel whose per-org credential row does not exist resolves inbound to
   nobody — the gateway drops the reply with no shadow copy for you to
   recover. Confirm under **Settings → Channels**.
4. **Check subscription scope.** `GET /api/v1/webhooks` returns each
   registered endpoint with its subscribed `events` list.
   `message.received` must be on it (or
   `normalized.inbound` — see
   [Normalized inbound envelope](/webhooks/normalized-inbound-envelope)).
5. **Filter on the right `channel` field.** A handler that sees
   `channel: "sms"` on the contact's fallback thread never sees
   `channel: "line"` on a fresh LINE reply — the semantic filter has to match
   the actual channel of the inbound event.

## A worked example — inbound that dies on the credential layer

A WeChat subscriber set `DEVOTEL_WECHAT_ACCESS_TOKEN` (the platform default)
and removed the per-org row, intending every tenant to fall through to the
platform OA. Replies stopped. Delivery list for `message.received` is empty.

Resolution: the per-org row is removed, and the gateway resolves inbound by
**organization** — a reply addressed to the removed row's OA is identified
against the credential row that no longer exists. When the platform default
visits inbound it must claim the reply for some organization; with all
per-org rows gone, no organization claims it, and the relay drops the event.
Re-add the per-org row under **Settings → Channels → WeChat** and replies
land again, keyed to that OA.

## What not to try

* **Do not filter on a channel other than the inbound one.** A handler that
  keys on `channel: "kakao"` when Zalo replies are in scope never sees them —
  the gateway tags each inbound event with its actual channel and the
  semantic filter has to match that value, not the one you meant.
* **Do not treat a gateway-relayed miss like a console-webhook wiring miss.**
  LINE's webhook URL is the only wiring layer you control; the other three
  channels deliver automatically and only stop on credentials or filtering.
* **Do not retry a deterministic 503 `CHANNEL_NOT_CONFIGURED` against
  inbound.** If outbound is failing closed, inbound has no identity either —
  connect the channel first, then re-test. See
  [WeChat and Zalo credential resolution](/troubleshooting/wechat-zalo-credentials).

## Escalation bundle

Open a support ticket only when this page is exhausted — expect inbound
on a credential row checked, a subscription scoped to `message.received`,
and LINE's console URL verified when LINE is in the mix. Include:

* The **channel**: `line`, `kakao`, `wechat`, or `zalo`.
* Your **tenant id** (dashboard → Settings → Organization, or `organizationId`
  on `GET /api/v1/me`).
* The **time window** (with timezone) of the missed inbound event.
* The **webhook endpoint id** if you were expecting `message.received`.
* For LINE, a screenshot of the **Messaging API → Webhook URL** configuration.

## See also

* [LINE inbound never arrives](/troubleshooting/line-webhook-setup) — the
  provider-registered webhook wiring
* [KakaoTalk template gates](/troubleshooting/kakao-template-gates) — after
  inbound is resolved, the send-side content gates
* [WeChat and Zalo credential resolution](/troubleshooting/wechat-zalo-credentials) —
  the per-org vs platform-default chain this page's inbound depends on
* [Inbound WhatsApp or RCS message never arrives](/troubleshooting/inbound-channels-no-route) —
  the sibling page the APAC matrix extends
* [Inbound SMS no route](/troubleshooting/inbound-sms-no-route) — the
  root-style page for the whole inbound family