Choose your first path
You do not need to read everything before sending a controlled test. Start with the path closest to the work you are doing now.
Event in. Alert out. Reply back.
Your application owns the business event and customer record. ChatRail operates the WhatsApp connection, records message state and delivers inbound events to your endpoint.
- 01Pair a number
An authorized workspace user scans a short-lived QR code.
- 02POST the alert
Your server sends customer copy and an optional structured context object.
- 03Track delivery
Sent, delivered, read and failed remain distinct message states.
- 04Process the reply
A signed webhook returns the inbound message to your application.
A server-side send
Use an API key from a trusted server and reuse the same idempotency key when retrying an uncertain request.
curl -X POST https://api.chatrail.dev/v1/messages/text \
-H "Authorization: Bearer $CHATRAIL_API_KEY" \
-H "Idempotency-Key: order-2048-dispatched" \
-H "Content-Type: application/json" \
-d '{
"connection": "operations",
"to": "+14155550142",
"body": "Order CR-2048 has shipped.",
"context": {"order_id": "CR-2048", "status": "dispatched"}
}'Validate recipient input, restrict keys to a workspace and rotate them if exposure is suspected.
Technical guides
Build an end-to-end workflow
Each tutorial includes the event boundary, payload contract, reply behavior, failure handling and a production checklist.
Know the boundary
ChatRail currently uses WhatsApp Linked Devices, not Meta’s official Cloud API. Sessions can require re-pairing, account enforcement remains controlled by WhatsApp and recipient consent is still your responsibility.
Pause unhealthy connections, bound retries, surface failures and assign an owner for re-pairing before sending production traffic.