Troubleshooting channels (messages not arriving)

When customer messages stop arriving in your Wassla inbox, the cause is almost always one of four things: the channel is suspended or unassigned in Wassla, the webhook signature settings are misconfigured at the provider, the provider has paused delivery on their side, or the inbound payload is being dropped because Wassla cannot resolve it to a connected channel. Walk this checklist top to bottom — most teams isolate the failure in under ten minutes.

Step 1 — Check the channel status in Settings

Start in Wassla, because if the channel is disconnected or suspended on our side, no provider configuration will help.

  1. Open Channels from the left sidebar of your workspace.
  2. Locate the tile for the affected channel (WhatsApp, Instagram, Facebook Page, Twilio SMS, Twilio Voice, or the embedded web widget). A connected channel shows a colored status badge and the relevant identifier underneath — for WhatsApp that is the display phone number, for Instagram the IG user handle, for Facebook the Page name.
  3. Confirm the tile shows Connected. A grey or red chip means the channel row was deleted or the access token was revoked upstream. Click Manage, then Re-authorize (Meta channels) or re-paste the Twilio number to repair it.
  4. Confirm an agent is assigned. If the assignment dropdown is empty or points to a draft (unpublished) agent, the inbound webhook handler will drop the payload before any AI work runs. Pick a published agent from the dropdown and click Save.
  5. Open the workspace header and confirm your billing mode. If the amber "Pre-live: AI replies are off" banner is visible, the agent will not respond — that is by design. Go to Settings then Billing to switch to demo or live mode before testing.

If your workspace is suspended, every inbound webhook returns a 2xx ack to the provider but the message is silently dropped — by design, to protect against runaway AI spend. Contact Wassla support to lift the suspension; existing in-flight conversations continue, only NEW activity is blocked.

Step 2 — Verify webhook signature settings at the provider

Wassla expects every Meta and Twilio webhook to arrive without a Supabase JWT and with the correct provider signature. A misconfigured signature is the most common silent failure for self-served channels.

Meta channels (WhatsApp, Instagram, Facebook Page)

  1. In your Meta Business or Meta for Developers console, open the app that holds the channel and go to Webhooks.
  2. Confirm the Callback URL matches the one Wassla shows on the Manage modal for the channel — typically https://zthlossdwwvjieeyktfd.supabase.co/functions/v1/<whatsapp|instagram|facebook-page>.
  3. Confirm the Verify Token matches the one Wassla generated for you (visible during the connect flow). A mismatched verify token causes Meta's initial subscription GET to fail, after which Meta stops sending events.
  4. Confirm the relevant subscription fields are checked — messages for WhatsApp, messages plus messaging_postbacks for Instagram, messages plus feed for Pages.

If you connected through Embedded Signup, all of these are set automatically. If you set them by hand, double-check spelling and trailing whitespace.

Twilio (SMS and Voice)

  1. In the Twilio console, open Phone Numbers then your number, and scroll to Messaging (for SMS) or Voice & Fax (for calls).
  2. The inbound webhook URL must be the Wassla endpoint Wassla showed you on the Twilio tile — typically https://zthlossdwwvjieeyktfd.supabase.co/functions/v1/twilio-sms or .../twilio-voice. The HTTP method must be POST.
  3. Confirm the Twilio Auth Token in your account matches the one Wassla has on file. If you rotated your Auth Token in Twilio, the signature check will start failing — push a re-rotation through Wassla support so both sides match.

Wassla webhook handlers are intentionally public (no JWT). If you see 401 errors in your Twilio or Meta dashboards, that means the function was accidentally re-deployed with JWT verification enabled — contact Wassla support, because that is a regression on our side, not yours.

Step 3 — Check the Twilio or Meta provider dashboard

If Wassla and the webhook settings look right, the provider may simply not be sending the message yet.

  1. Meta: in the Meta for Developers app, open WhatsApp then API Setup, or the equivalent Instagram or Page section, and view the Webhook deliveries log. Each inbound event is listed with the HTTP status Wassla returned. A 2xx means Wassla accepted the payload (continue to Step 4). A 4xx or 5xx means the call did not reach Wassla cleanly — check the response body for the error code.
  2. Twilio: in the Twilio console, open Monitor then Logs then Messaging (or Calls). Click the specific message or call SID and inspect the Request Inspector. You will see the exact webhook request Twilio sent, the response Wassla returned, and the latency. A 401 or 403 indicates a signature mismatch; a 500 indicates a Wassla-side error worth reporting.
  3. Also check the provider's delivery status for the underlying message. WhatsApp messages with failed status, Instagram messages outside the 24-hour reply window, and Twilio messages on numbers without A2P 10DLC registration will never reach Wassla because the provider blocked them upstream.

Step 4 — Check the Wassla audit log and inbox for inbound events

If the provider says it delivered the webhook with a 2xx, the message reached Wassla — the next question is whether Wassla routed it to a conversation.

  1. Open Inbox in the sidebar and filter by the channel. A real inbound message creates a conversation within five seconds. If the conversation is there but the AI did not reply, the issue is an agent or credit problem rather than a channel problem — see Train your AI agent.
  2. Open Settings then Audit log and filter by date range. The audit log captures channel configuration changes, suspensions, and billing-mode flips — useful for confirming whether someone disconnected the channel or switched the workspace to infra-only mode without telling you. See Read the Wassla audit log for filter tips.
  3. If you see the webhook reach Wassla in the provider dashboard but nothing appears in the inbox or the audit log, the inbound id (phone number id, page id, or widget key) is not resolving to a connected channel row. The handler returns the channel-appropriate 2xx ack to the provider and drops the payload to prevent silently building a backlog of unrouted messages. This usually means the channel was reconnected to a different workspace or with a different identifier — go back to Step 1 and confirm the identifier on the tile matches the one the provider is sending.
  4. If none of the above explains it, open the channel detail page and click Test connection. The synthetic test bypasses the provider entirely and pushes a message through Wassla's pipeline so you can isolate whether the break is at the provider edge or inside Wassla.

When to contact Wassla support

Open a support request from the channel detail page if any of the following are true: the provider dashboard shows 5xx responses from Wassla, the audit log shows a suspension you did not request, the test connection succeeds but real messages still do not arrive after fifteen minutes, or you see webhook deliveries arriving but no conversations being created. The support request automatically includes the channel diagnostic bundle so the on-call engineer can correlate against our server logs.