Skip to main content

Webhook

Webhooks are user-defined HTTP callbacks that are triggered by specific events. Whenever a triggering event occurs, the WhatsApp Business API client sees the event, collects the data, and immediately sends a notification (HTTP request) to the WhatsApp URL specified in the application settings, updating the status of sent messages or indicating when you receive a message.
It is important that your Webhook returns an HTTPS 200 OK response to notifications. Otherwise, the WhatsApp Business API client will consider that notification a failure and will retry after a delay.

Webhook Configuration

To receive notifications, the customer needs to register the Webhook URL on the number. Set/update the Webhook URL:
The webhook field is optional (it can be null to remove it) and has a maximum of 255 characters. If the Webhook URL is not set, notifications will not be delivered.
If your Webhook URL sits behind a firewall or allowlist, allow the Positus source IPs. See Webhook IP addresses.
In addition to the main Webhook, you can configure a secondary webhook (secondary_webhook). When set, it receives the same notifications as the main Webhook.
Test the Webhook (handshake): to validate that the URL is responding correctly, trigger a test message. Positus will send a test notification ("Beep Beep!") to the configured URL:
It is important that your Webhook returns an HTTP 200 OK response to notifications. Otherwise, the notification will be considered a failure and there will be retry attempts.

Set notification settings

Positus numbers use the WhatsApp Cloud API. On the registered Webhook URL, the customer receives a normalized subset of Meta’s payload (without the entry/changes envelope). The delivered objects are the raw Cloud API objects.
Whenever possible, names will be kept constant across functions. (For example, all date and time stamps are named timestamp.
New user identifiers (BSUID). With the arrival of WhatsApp usernames, webhook payloads now carry additional identification fields — user_id (BSUID), parent_user_id (parent BSUID) and profile.username. When a user adopts a username, the phone fields (wa_id, from, recipient_id) may be omitted from the payload. Handle this scenario by using user_id as the primary identifier. To understand these identifiers, see the BSUID and user identifiers page.

Notification Webhook format

An incoming message notification has the top-level { "contacts": [...], "messages": [...] }. A status notification has the top-level { "statuses": [...], "contacts": [...] } (contacts is only present when the status is not failed). Example (incoming text message)
The profile.username, user_id and parent_user_id fields only appear in the scenarios described on the BSUID page. The wa_id (and the message from) may be omitted when the user has adopted a username. The fields below are added to the contacts[] object (they do not replace the existing ones):
The messages[].from field (sender’s phone number) follows the same behavior as wa_id: it may be absent when the user has adopted a username. Use the user_id present in the corresponding contacts[] object to identify the sender durably.

Message status updates

In addition to incoming messages, the customer receives status notifications for the messages they sent. These notifications have the top-level { "statuses": [...], "contacts": [...] }. Example (delivered status)
The BSUID identification fields in the status object: The contacts array that accompanies the status (when present) carries the same BSUID fields described in incoming messages: user_id, parent_user_id and profile.username. The status field can take the following values: When the status is failed, the status object includes an errors array with the failure details and contacts is not sent. Example (failed status)

Notification errors

When out-of-band errors occur during the normal operation of the application, the errors array will provide a description of the error. This type of error can be caused by temporary network connectivity errors, invalid credentials, management controllers with an unavailable status, and so on. If you receive an error, refer to Error and status messages for more information. Example
The errors object
The errors object contains the following parameters:

Incoming message notifications

You receive a notification when your business receives a message. The messages object section presents all the information that can be received about an incoming message.

Example: Incoming Text message

Example: Incoming static location message

Example: Incoming message with contacts

System message: user changed identifier (user_changed_user_id)

When a user’s identifier changes (for example, when switching phone numbers), WhatsApp sends a system message of type system with system.type equal to user_changed_user_id. It arrives inside the messages array, in the same format as other incoming messages. Use it to update the contact’s link to the new user_id.

Incoming media message notifications

When a message with media is received, the notification sent to your Webhook contains a media object with the fields that identify the file. In the Cloud API, the media object only carries id, mime_type, and sha256 (plus an optional caption for image, document, and video). There are no file or link fields. To download the media, use the id in the download endpoint: GET https://api.positus.global/v2/whatsapp/numbers/{chave}/media/{id}.

Example: Incoming message with image

Example: Incoming message with document

Example: Incoming message with audio

In the Cloud API, audio messages (including voice messages) are delivered with the type audio, not voice.

Example: Incoming message with video

Example: Incoming message with sticker

Incoming replies to sent messages

Users can reply to a specific message on WhatsApp. So that the business understands the context of the reply to a message, we include the context object. This context object provides the id of the message the customer replied to and the WhatsApp ID of the sender of the original message.

Example: Customer replied to your message

Workspace event webhooks (BSUID)

In addition to message and status notifications (delivered in the raw Cloud API format), Positus sends two workspace events related to BSUID. These events use a different envelope: a top-level object with the event field (event name), the workspace object (workspace identification) and an object with the event data — named contact or number, depending on the case.

BSUID update (user_id_update)

Triggered when a user’s BSUID (or parent BSUID) is updated. It carries the previous and current values of each identifier. The data comes in the contact object.

Line username update (business_username_update)

Triggered when the status of your official line’s username changes (the public @name of the business number). The data comes in the number object.

Official WhatsApp Cloud API documentation

Positus uses the WhatsApp Cloud API and delivers the objects in the same format as Meta’s official standard. The complete and up-to-date documentation can be found at the link below:https://developers.facebook.com/docs/whatsapp/cloud-api/webhooks/components