Use n8n to process IllyVoIP call or SMS events after verifying their signature and recording them durably. This guide uses a small verification receiver in front of n8n, which avoids relying on hosted-workflow access to raw request bytes or restricted crypto modules. The receiver is your application component, not an additional IllyVoIP service.
1. Choose where verification and durability happen
The flow is: IllyVoIP → HTTPS verification receiver → durable inbox → authenticated n8n production webhook. Reuse the existing IllyVoIP Node.js signature-verification guide for the public receiver. Keep its webhook signing secret separate from the account API key and from the credential used between the worker and n8n.
The receiver verifies Illyvoip-Signature against the timestamp, a period and the exact raw JSON bytes using HMAC-SHA256. Follow the documented header parser and timestamp checks; do not parse and reserialize the body before verification. Invalid requests must not reach n8n. A generic secret URL is not equivalent to signature verification.
2. Create the n8n receiver workflow
- Create a workflow with a Webhook trigger using POST and a deliberate path.
- Configure Header Auth or another appropriate supported authentication method for the private worker-to-n8n connection. Store the credential in n8n’s credential system and in the worker’s secret store.
- During development, use the Test URL only while listening for a test event. Use the Production URL for the deployed worker after publishing/activating the workflow as required by your n8n version.
- Choose a response mode that lets you acknowledge only after your intended durable acceptance checkpoint. Add Respond to Webhook where explicit response control is needed.
3. Persist before acknowledging IllyVoIP
After a valid signature, store the event with its stable event ID, endpoint/account scope and payload hash in a durable database or queue. Make repeated delivery of the same verified event idempotent. A duplicate with conflicting content needs investigation; do not silently replace the original record. Return success to IllyVoIP only after that durable write succeeds.
If the database is unavailable, return a failure so the delivery can be retried. Do not acknowledge first and hope an in-memory task finishes. The inbox worker should separately record when the event is ready, being handed to n8n, completed or awaiting retry. Workflow static data alone is not the durable inbox for this design.
4. Hand off a verified event to n8n
The worker sends the stored event to the authenticated Production URL, including a stable delivery reference in its JSON envelope. Mark it as a verified event in your own schema; do not invent an IllyVoIP field or forward the account API key. Send only the data the workflow needs. Decide whether a successful n8n response means durable job acceptance or completed processing, and implement that checkpoint consistently.
A response lost after n8n accepted the event can cause a retry. Make the resulting business action idempotent as well: one CRM update, ticket or notification per intended event/action identity. The upstream inbox’s uniqueness alone cannot prevent duplicate downstream effects if the worker repeats an uncertain handoff.
5. Route the actual event type
Use a Switch or equivalent node on the event type your receiver forwards. Process SMS delivery updates against a stored IllyVoIP message ID; keep delivery separate from billing/refund fields. Process call events against the actual call identity. Ignore or quarantine unrecognised event versions deliberately rather than treating every payload as an SMS.
Do not configure the workflow to send another paid SMS for every retry or status transition unless that is a separately authorised business requirement. Receiving an event is not permission to contact a customer. When the workflow does send through IllyVoIP, use the existing outbound n8n SMS guide and a stable message intent.
6. Test both acknowledgements and recovery
Use synthetic signed fixtures to test valid and altered bodies, expired timestamps, duplicate events, database failure and a worker response lost after n8n acceptance. Confirm that failed verification never starts the workflow, a failed durable write does not return success, and replay cannot repeat the business action.
Then verify the correct production URL, workflow state and private worker credential with a deliberate non-billable fixture. n8n’s test listener and a successful HTTP response alone do not prove production processing is complete. For direct signature verification inside self-hosted n8n, pin and test your version’s raw-body, binary-data and crypto configuration first; this gateway walkthrough does not claim those settings work on every hosted plan.
Related guides
- Verify IllyVoIP webhook signatures in a Node.js receiver
- Troubleshoot webhook delivery
- Send SMS from n8n with the IllyVoIP API
- Send an SMS with the IllyVoIP API and track delivery
Reference
Current instructions and technical reference: n8n Webhook node, n8n Respond to Webhook node.
Reviewed 12 October 2026 against the current IllyVoIP controls, implementation and applicable references. Available options depend on account permissions and service state.