Is this the same as Telegram or Discord notifications?

No. Operator alerts to chat apps are a separate product area—see the Notifications feature page. Developer webhooks target your backend for automation and data sync.

Do webhooks work on Free?

Developer webhooks are part of the API/developer surface and follow the same plan rules as REST access—starting Starter ($29/mo), not on Free.

Can I assume exactly-once delivery?

Design for at-least-once: use a stable event id from the payload to dedupe, return 2xx quickly, and process in a worker.

Where is the payload schema?

On docs.waping.app, alongside verification and security headers for your workspace version.

Event delivery

Developer webhooks
your server, WAPing’s events

Stop polling the API for every change. Subscribe an HTTPS endpoint and let WAPing POST structured events when conversations and devices move—built for queues, idempotent workers, and CRM sync.

Get started free Webhook guide (site)

HTTPS callbacks

Retries & idempotency

Inbound + delivery signals

Verify signatures

HTTPS to your URL

Developer tier from Starter ($29/mo)

Dedupe on event id

Contrast with Meta webhooks

Pain point

Polling hides outages and burns rate limits

If your integration only pulls message logs on a timer, you add latency, race with 429s, and still miss fast failures. Webhooks flip the direction: WAPing calls you when state changes, so workers react in near real time.

Why it matters

Event-driven design matches how support and commerce actually behave: spikes are bursty, and your stack should enqueue work instead of hammering list endpoints.

One clear capability

Configurable HTTPS subscriptions that deliver workspace events to your infrastructure, with retry semantics documented on docs.waping.app.

How it works

Register a public HTTPS URL in developer settings (exact UI labels may vary).
Complete verification when prompted—challenge flows are versioned in the canonical docs.
Return 2xx quickly; offload parsing to a queue worker.
Dedupe using the event identifier in the payload; expect occasional duplicates on retries.

Practical examples

Ticket creation — on inbound message, enqueue a job that creates or updates a row in your helpdesk.
Session guardrails — on disconnect events, pause campaigns and notify operators via notifications.
Warehouse sync — append events to an outbox table for downstream ETL without exposing database credentials to WAPing.

Caveats

Payloads differ from Meta Cloud API—plan an adapter if you multi-home providers.
Your endpoint must be reliable; repeated failures trigger backoff and may pause delivery until healthy.
Signature or shared-secret validation is documented per product version—do not skip verification on production URLs.

Wire your first handler

Confirm plan access, then follow the canonical webhook tutorial.

Open app Pricing docs.waping.app

REST API

Outbound control plane for sends and workspace operations.

Integrations hub

Patterns for Zapier, n8n, and custom stacks.

Automation flows

In-app triggers beside raw HTTP handlers.

Where this fits

HTTPS callbacks replace polling when conversations and devices change. Typical flows: support automation, order-driven messaging. Technical entry points: Webhooks guide, Full API reference. Plans and API access are on pricing.

FAQ

Straight answers—same facts as our pricing and security pages.

They are outbound HTTPS POST requests from WAPing to a URL you control, carrying JSON when something happens in your workspace (for example inbound messages or session changes). They are not the same as Meta’s Cloud API webhook format.

support automation order-driven messaging Webhooks guide Full API reference Pricing API quickstart Open app

Developer webhooksyour server, WAPing’s events