WhatsApp via Infobip

How the channel works

WhatsApp on Infobip is the same transport as SMS on Infobip — one inbound webhook URL (https://…/api/channels/{channelId}/inbound?secret=…) authenticated by the secret in the URL — with two differences: the sender is an Infobip-registered WhatsApp sender, and outbound replies go to Infobip's WhatsApp endpoint (/whatsapp/1/message/text) instead of the SMS one. If you have already connected SMS on Infobip, everything below will feel familiar.

What you need

• An Infobip account.
• An Infobip-registered WhatsApp sender.
• Your API key and your account base URL.

Connect

1. 1
   On the chatbot's Channels tab, add a WhatsApp channel, choose Infobip, and fill — all three required:

   Field	Value
   API key	Infobip portal → Developers → API Keys
   Base URL	The xxxxx.api.infobip.com host — paste it as https://xxxxx.api.infobip.com
   Sender	Your Infobip-registered WhatsApp sender

   The base URL is validated to match https://<subdomain>.api.infobip.com exactly — at connect and again on every send.

2. 2
   Copy the webhook URL shown after connecting — it already carries a ?secret=… query param, shown once. Treat the whole URL as a credential and keep it private; the connected-channels list masks it afterwards, and losing it means reconnecting the channel.
3. 3
   In the Infobip portal, set that full webhook URL (including ?secret=) as the sender's inbound-message webhook and its delivery-report webhook — both point at the same channel URL.

How webhooks are verified

Infobip does not sign webhooks: the secret in the URL is what authenticates its calls, compared in constant time on every request. A wrong or missing secret is rejected (403) and flips the health chip to Signature rejected. A single Infobip POST can carry inbound messages and delivery reports together; both are processed. Credentials are stored encrypted.

Connect with the API

`POST /channels` takes the same three credentials. config.provider selects the transport — infobip here — and all four keys are required:

{
  "type": "whatsapp",
  "chatbotId": "3f2504e0-4f89-41d3-9a0c-0305e82c3301",
  "config": {
    "provider": "infobip",
    "apiKey": "…",
    "baseUrl": "https://xxxxx.api.infobip.com",
    "fromNumber": "447860099299"
  }
}

Omit provider and the call fails 422 with "Pick a provider for this channel." baseUrl must match https://<subdomain>.api.infobip.com exactly — anything else is rejected at connect, because that host is used to build every outbound call. The inboundSecret in the response is the ?secret= value for this channel's webhook URL, shown once: Infobip does not sign webhooks, so that secret is the whole of its inbound authentication. The same credentials connect SMS and Voice; only type changes.

Verify it works

Message the WhatsApp sender. The conversation should appear in the Inbox tagged WhatsApp, and the AI should reply. The health chip separates "Infobip is not calling us" (No messages yet) from "Infobip is calling with a bad secret" (Signature rejected).

Message flow

Inbound messages link the sender to a contact by phone number, join their open WhatsApp thread on this chatbot (or start a new one), and are deduplicated by provider message id so Infobip retries never duplicate. An inbound message can carry one media URL — download anything you need to keep, provider links can expire.

With AI replies on (default), the AI answers new threads through the same grounded pipeline as the widget; asking for a person escalates to the inbox wait queue. Off, every new thread lands flagged needs_human. A failed AI turn degrades to the human queue rather than going silent.

Replies are normalised for WhatsApp — markdown bold becomes WhatsApp's single-star *bold*, links become label: url. Outbound is text-only: no attachments, and no template messages.

The 24-hour window

WhatsApp only allows free-form replies inside a 24-hour customer-service window, which resets on each customer message. Outside it, the provider refuses the send: the message is marked Not delivered with the provider's reason. Evoriqa does not send re-engagement template messages, so a conversation that went cold has to be restarted by the customer.

Delivery reports

Infobip posts delivery reports to the same channel webhook, synced onto each outbound reply's row: DELIVERED → Delivered; UNDELIVERABLE, REJECTED, EXPIRED → Not delivered with the stored reason and a one-click Retry. Intermediate PENDING/ACCEPTED reports are ignored, and statuses only move forward — a late report never downgrades a message. Infobip does not expose the read receipts or typing indicator that the Meta Cloud API provides.

Limits

• Inbound webhook: 120 requests per minute per channel/IP; body capped at 2 MiB.
• Inbound media: 1 attachment per message.
• Outbound: free-form text only.
• A paused channel rejects new inbound but still delivers replies to open threads.
• One sender = one channel; connecting it twice shows a duplicate-number warning naming the other bot.

Troubleshooting

Where to go next

• WhatsApp via Meta Cloud API
• WhatsApp via Telnyx
• SMS · Voice — the same Infobip credentials.
• Channels overview