Skip to content
DevelopersBuild with YallaBuy
Merchant guide
HTTPS · Signed events

Receiver endpoint security requirements

These rules are enforced at creation, on every delivery attempt, and on every redirect hop — anything that fails them is rejected by the platform itself.

Start building
Reviewed against implementation
YOUR INTEGRATION, AT A GLANCE
Webhook delivery · Headers
POST /your-webhook-endpoint
Content-Type: application/json
webhook-event-type: order.created
webhook-id: <endpoint_id>
webhook-event-id: <event_id>
webhook-delivery-id: <delivery_id>
webhook-timestamp: <unix_seconds>
webhook-signature: v1=<hmac_sha256_hex>
See the implementation
On this page

01Platform rules

  • HTTPS only — any other protocol is rejected at creation, and the only allowed ports are 443 and 8443.
  • Public addresses only: the hostname is resolved and every candidate address is checked — loopback, private ranges (RFC1918), link-local including cloud metadata 169.254.169.254, CGNAT, reserved IPv6 ranges, and wrapped forms (IPv4-mapped and NAT64) all resolve to BLOCKED_HOST.
  • No userinfo in the URL (user:pass@host) — rejected.
  • Redirects: at most 3 hops, and every hop re-runs the full validation — a redirect to a forbidden target returns REDIRECT_BLOCKED.
  • The connection is pinned to the validated address — DNS changing after the first lookup (DNS rebinding) opens no door to any internal address.
  • The TLS certificate must be valid and match the hostname — a failed handshake is classified TRANSPORT_ERROR.

02Your responsibilities

  • Respond 2xx fast — the platform waits only 10 seconds; do the heavy work after responding.
  • Make your handler idempotent — duplicates are normal in this system (see the idempotency page).
  • Verify the signature on every request — and reject anything that fails verification without processing it.

Keep exploring

Quick start — your first webhookThe delivery lifecycle and retriesVerifying the signature

COMPLETE YOUR INTEGRATION