Check which endpoint should receive the event
Open Settings → Integrations → Webhooks. Confirm the endpoint is enabled and subscribed to the event you need. Account-webhook permission covers endpoints, secrets and delivery logs for the whole account; CRM permission alone does not grant this access.
For SMS, review the Sender ID selection. All Sender IDs includes every subscribed SMS event for the account; a selected list matches the original message sender. Other event types are unaffected.
Changing a filter does not replay history
Sender selections are checked for each delivery attempt, including retries. Changing them does not replay old events or redirect already queued deliveries.
Read the delivery attempt
The Delivery log shows time, status, event, endpoint, HTTP response and error. Match the event and endpoint to the attempt you are investigating, then compare it with your receiver’s logs.
- No matching attempt
- Check event subscriptions, endpoint state and SMS Sender ID filters before investigating receiver code.
- A failed attempt
- Use the HTTP response or network error to identify the receiving layer that rejected or missed the request.
- A successful acknowledgment
- Check your application processing separately. An HTTP acknowledgment does not prove every downstream action completed.
Use the current delivery-IP list in account settings if your firewall restricts incoming requests. Verify signatures even when an IP allowlist is in place.
Check signature verification first
IllyVoIP sends JSON POST requests with an Illyvoip-Signature header. Verify it using the webhook secret and the original raw request body before processing the event.
The signed input is the timestamp, a period and the raw body. Parsing and re-encoding JSON before verification can change that input. Use the current reference for the exact HMAC SHA-256 procedure.
A webhook signing secret is separate from your customer API key. If the secret was rotated, update the receiver through your normal credential-change process. Do not reveal either secret in support logs.
Understand the HTTP response
- Any 2xx
- Acknowledges delivery. An empty 200 response is sufficient.
- Network failure, no response, 408, 429 or 5xx
- Eligible for retry under the documented retry policy.
- 3xx or other 4xx
- Stops delivery. Check redirects, access rules and receiver validation rather than waiting for an automatic retry.
Acknowledge valid events promptly and queue slow work separately. Keep your receiver safe to run more than once for the same event.
Use the event ID to avoid duplicate work
Store the body’s id as the stable deduplication key. The Illyvoip-Delivery header identifies the delivery job; it is not a replacement for the event ID.
For SMS correlation, follow the current send-response and webhook documentation. Delivery-job IDs and message identifiers serve different purposes.
If you need help, provide the event ID, attempt time and timezone, response code and a sanitized receiver error. Keep signing secrets, API keys and unrelated event contents private.