Skip to main content
Xobito has two separate webhook systems. They share the word “webhook” but do very different things — pick the right one for the job.
  • Flow A — Outbound CRUD webhooks. Xobito fires events when contacts, statuses, or sources are created, updated, or deleted in your workspace. Configured under Settings → Webhook Settings (the CRUD section). Documented at Webhooks Overview.
  • Flow B — Meta webhook forwarder. Xobito receives every WhatsApp webhook Meta sends to your WABA (account alerts, message echoes, quality ratings, etc.) and can forward the ones you care about to your own URL. Configured under Settings → Webhook Settings in the “Webhook Resend” section.
This page documents both, focuses on Flow B (which has no standalone page until now), and helps you pick the right tool.

​
The two flows at a glance

Flow A — Outbound CRUDFlow B — Meta forwarder
Source of eventsYour Xobito workspaceMeta (WhatsApp Cloud API)
Events availableContact, Status, Source — create/update/delete30+ Meta webhook fields (messages, calls, flows, quality, account updates, etc.)
Signed?Yes — HMAC-SHA256No signature — see security note
Retries on failure3 retries, 0/2/4s backoffNone documented
Timeout30sRelies on Meta’s delivery to Xobito
Typical useSync your CRM when a contact is edited in XobitoMirror Meta events to an automation platform, data lake, or CRM
DocsWebhooks OverviewThis page

​
When to use Flow A vs Flow B

Use Flow A when...

You edit records inside Xobito and want another system to learn about the change — for example, update a HubSpot contact when an agent edits the Xobito contact record.

Use Flow B when...

You want a copy of raw WhatsApp webhook events from Meta — for example, pipe incoming customer messages into an n8n workflow, or record template quality changes in your data warehouse.
Flows are independent. You can enable neither, one, or both.

​
Flow B — Meta webhook forwarder

Meta sends your WABA all kinds of webhook events: incoming messages, delivery status, template approval updates, phone-number quality changes, flow events, and more. Xobito receives and processes them so the dashboard, campaigns, and bots work correctly. The Webhook Resend feature does one extra thing: for the event fields you tick, Xobito also re-posts the payload to a URL you choose, so your own systems get a copy.
Webhook settings page

​
Enable forwarding

1

Open Settings → Webhook Settings

Sidebar → Settings → Webhook Settings.
2

Turn on 'Enable Webhook Resend'

Flip the master toggle. Until this is on, nothing is forwarded.
3

Enter your destination URL

Paste the full HTTPS URL of the endpoint that should receive the events.
4

Optionally set a method label

Free-text label used to describe the request style to your operator (e.g. POST, POST-JSON, Zapier-hook). This is a note, not a validated HTTP verb — Xobito does not change how it calls your endpoint based on this value.
5

Select which Meta fields to forward

Tick the boxes next to the event fields you care about. Leave the rest unticked to avoid noise.
6

Save

Changes take effect immediately. The next matching Meta event will be re-posted to your URL.

​
Field reference

​
enable_webhook_resend
boolean
default:"false"
Master on/off switch. When false, no events are forwarded regardless of which fields are ticked.
​
whatsapp_data_resend_to
string
required
Destination URL that receives the forwarded payload. Must be a valid URL (Laravel url validator), max 255 characters. Required when enable_webhook_resend is true. Use HTTPS in production.
​
webhook_resend_method
string
Free-text label (max 255 chars). Stored as-is in workspace settings — useful for documenting how your endpoint expects the request, or which integration it belongs to. Does not change Xobito’s delivery behaviour.
​
webhook_selected_fields
array
JSON array of Meta webhook field slugs to forward — see the full list below. Only ticked fields are forwarded; everything else Xobito receives from Meta is handled internally and not re-posted.
All input is sanitised via Xobito’s PurifiedInput rule (strips control characters, normalises whitespace). Very long labels or URLs are rejected at 255 characters.

​
Security of forwarded events

Forwarded payloads are not signed by Xobito. Unlike Flow A (outbound CRUD webhooks), there is no HMAC-SHA256 signature on Flow B. Your endpoint cannot cryptographically verify that a request came from Xobito.
Because forwards are unsigned, treat your receiver conservatively:
  • Always use HTTPS for whatsapp_data_resend_to — this protects payload integrity in transit.
  • Validate the payload shape on your side before trusting it. Reject requests that don’t match Meta’s documented schema.
  • IP allowlist if possible. Xobito forwards from the same server that talks to Meta — keep that server’s egress IPs in a short list and allow only those.
  • Rotate the URL if you believe it’s leaked. Treat the URL itself as a weak secret.
  • Don’t trigger destructive actions (deletes, refunds) directly from a forwarded event without a second check — poll Xobito’s API to confirm before acting.

​
Meta fields you can forward

Xobito enumerates 30+ Meta webhook fields in the settings page. Pick only what you need — each extra field ticked means more traffic to your endpoint.
Fire when your WhatsApp Business Account state changes — useful for compliance and ops dashboards.
FieldFires when
account_alertsMeta issues an alert against your WABA
account_review_updateYour WABA completes / fails a review
account_settings_updateBusiness-level settings change (display name, profile)
account_updateGeneric account state change
business_capability_updateYour business-tier limits change (messaging tier up/down)
business_status_updateYour business verification or status changes
FieldFires when
callsA WhatsApp call event occurs (if your WABA has calling enabled)
FieldFires when
flowsA WhatsApp Flow is submitted by the customer — you receive the structured responses
FieldFires when
historyMeta sends historical conversation context (e.g. after re-connecting a number)
The highest-volume category. Think twice before enabling all of them.
FieldFires when
messagesAn incoming message from a customer — text, media, button clicks, reactions
message_echoesYour own outbound message is echoed back (for multi-client sync)
smb_message_echoesSmall-business app echoes (if relevant to your setup)
message_template_components_updateA template’s components change approval state
messaging_qualityQuality rating changes for your messaging
message_handoverA message is handed over between apps (two-app inbox)
FieldFires when
phone_number_quality_updateYour phone number’s quality rating changes (green/yellow/red)
phone_number_name_updateYour display name changes or is re-approved
securityA security-related event on your WABA
template_category_updateA template is recategorised by Meta
template_quality_updateA template’s quality rating changes
Fire for WhatsApp group-related updates (where your number participates).
FieldFires when
Group lifecycleA group is created / deleted
Group participantsA member joins or leaves
Group settingsGroup settings change (name, description, admin list)
Group statusGroup status changes
The settings page lists these as individual sub-fields — tick only the ones you need.
FieldFires when
payment_configuration_updateYour WhatsApp Pay / payments configuration changes
FieldFires when
web_app_data_syncWhatsApp Web / multi-device sync events
trackingAttribution / tracking events
user_preferencesA user’s WhatsApp preferences change (marketing opt-outs etc.)
Don’t tick every box “just in case”. Start with messages + phone_number_quality_update + template_quality_update — those cover most integration needs. Add more as you discover gaps.

​
Sample forwarded payload

Xobito forwards Meta’s payload as-is. Below is a representative example of an incoming-message event (messages field) for reference only — the exact shape is defined by Meta and can change. 
{
  "object": "whatsapp_business_account",
  "entry": [
    {
      "id": "WHATSAPP_BUSINESS_ACCOUNT_ID",
      "changes": [
        {
          "field": "messages",
          "value": {
            "messaging_product": "whatsapp",
            "metadata": {
              "display_phone_number": "15551234567",
              "phone_number_id": "PHONE_NUMBER_ID"
            },
            "contacts": [
              {
                "profile": { "name": "Jane Doe" },
                "wa_id": "15559998888"
              }
            ],
            "messages": [
              {
                "from": "15559998888",
                "id": "wamid.HBgMMTU1NTk5OTg4ODgVAgASGBQzRURFRg==",
                "timestamp": "1713266400",
                "type": "text",
                "text": { "body": "Is the order ready?" }
              }
            ]
          }
        }
      ]
    }
  ]
}
Consult Meta’s Cloud API webhook reference for the authoritative schema of each field.

​
Testing your endpoint

There is no built-in “Send test webhook” button on the Xobito settings page. To verify end-to-end you need to trigger a real Meta event. Practical ways:
  • Messages: send a WhatsApp message from a test phone to your business number.
  • Template quality: this is out of your control — rely on the messages test for wiring, and add monitoring for quality events later.
  • Phone number quality: same — wire it now, observe in production.
Point whatsapp_data_resend_to at a free request-inspection service (e.g. webhook.site) when you first set up. Once payloads look right, switch to your real endpoint.

​
Flow A — Outbound CRUD webhooks (summary)

Configured in the same settings page but under the Webhook URL / events section. Fires on contact/status/source create/update/delete events inside your workspace. Signed with HMAC-SHA256, retries three times with 0/2/4s backoff, 30-second timeout. See the full guide and payload schema at Webhooks Overview. Security and signature verification at Webhook Security. Full event catalogue at Webhook Events.

​
Troubleshooting

Check, in order:
  1. Is Enable Webhook Resend on?
  2. Have you ticked at least one field?
  3. Has a matching Meta event actually happened? (e.g. you ticked messages — send a message from a test phone.)
  4. Is your URL reachable from the public internet over HTTPS? Try a curl -X POST from another network to confirm.
  5. Is your endpoint returning a 2xx? Some receivers reject unknown content types.
Flow B has no documented retry policy. Build your receiver to be resilient:
  • Respond 200 fast, queue the payload internally, then process asynchronously.
  • If you need delivery guarantees, consider polling Xobito’s API to fill gaps, or use Flow A for the records you care about.
  • Make sure your certificate is issued by a public CA (Let’s Encrypt, DigiCert, etc.) — self-signed certs may be rejected.
  • Ensure your hostname matches the certificate’s SAN.
  • Disable HTTP/2-only features if your backend can’t handle Meta-scale throughput.
You probably ticked high-volume fields like messages or message_echoes. Narrow the selection or move event handling to a queue on your side.
Meta periodically updates its webhook schemas. Always validate incoming payloads defensively and log unexpected shapes rather than crashing.
Not supported in the current version. Mitigations:
  • Use HTTPS + IP allowlist.
  • Treat the destination URL itself as a weak shared secret (rotate if leaked).
  • If signature verification is a hard requirement, use Flow A for the Xobito-originated records you care about — those are signed.

​
Frequently asked questions

No — Flow B supports a single destination URL. If you need fan-out, deliver to one endpoint and re-broadcast from there (e.g. a small Lambda / worker).
No — filtering is at the field level only. Your receiver must do any finer-grained filtering (e.g. “only messages from VIP contacts”).
No. Your ticked fields are kept. Turning the master toggle back on resumes forwarding with the same selection.
No. Flow B is a best-effort copy of events. Xobito’s own processing of Meta events (so the dashboard, campaigns, and bots keep working) is independent of forwarding.

​
Next steps

Webhooks Overview

Flow A — outbound CRUD webhooks, signed, retried, ready for CRM sync.

Webhook Events

Full catalogue of Flow A event payloads, field-by-field.

Webhook Security

How to verify HMAC-SHA256 signatures on Flow A.

Meta's Cloud API webhooks

Authoritative schema for every Flow B payload.