Build WhatsApp workflows in n8n with ChatRail

Use standard n8n primitives

ChatRail uses JSON over HTTPS, so the workflow needs an HTTP Request node for sends and a Webhook node for replies. Store the API key and webhook secret in n8n credentials. Do not embed either value in a node field that will be included in workflow exports.

Normalize before sending

{
  "connection": "operations",
  "to": "{{$json.phone}}",
  "body": "{{$json.message}}",
  "context": {
    "event_id": "{{$json.event_id}}",
    "type": "{{$json.type}}"
  }
}

Validate the phone number, message length and required event fields before the HTTP node. Attach only the context required for later questions.

Make retries safe

Use the upstream event ID to construct one stable idempotency key. If the HTTP node times out, retry with the same key because the first request may already have succeeded. Route permanent validation failures to a review path rather than an infinite retry loop.

Create a separate reply workflow

Expose a production webhook endpoint, verify the ChatRail signature and branch by event type. Correlate the reply using identifiers in the event rather than searching message text. Restrict who can edit or activate the workflow.

Test before activation

Use one allow-listed number. Confirm the send, delivery event and inbound reply, then simulate a timeout and disconnected session. Only increase traffic after error routes are observable.

Frequently asked questions

Is this an official n8n integration?

No partnership is claimed. It is a tested HTTP and webhook implementation pattern.

Do I need a custom node?

No. Standard HTTP Request and Webhook nodes are sufficient.

Can n8n handle ChatRail retries?

Yes, provided the workflow verifies signatures and deduplicates events before side effects.

Build WhatsApp workflows in n8n with ChatRail

Trigger

Send

Continue