Skip to main content
Chatbot Manager → Automation → Webhook Workflows sends a WhatsApp template message whenever data arrives from an outside system through a webhook call. Each workflow is tied to one Message Template, and every field in the incoming data can fill in that template’s variables.

​
Step 1: Create the workflow

Chatbot Manager Automation tab with Webhook Workflows sub-tab selected, a list of existing workflows with their Sent, Delivered, and Opened stats, and a Create button
In Chatbot Manager → Automation → Webhook Workflows, click Create, then fill in Workflow Details:
Workflow Details form with Workflow Name set to Abandoned Cart Recovery, Message Template set to orderdetails, and a Create Workflow button, alongside the AI Workflow Assistant panel
  • Workflow Name — e.g. Abandoned Cart Recovery
  • Message Template — the approved template to send, e.g. orderdetails. If you want to create a new one, click here.
Click Create Workflow. This workflow’s purpose, as ChatSyncs describes it: “Set up workflow properties using data received from 3rd party webhook call.”
The AI Workflow Assistant panel alongside the form can configure most of this for you — tell it the provider (Stripe, PayPal, Shopify, etc.), the workflow name, or paste a sample JSON payload, and it offers shortcuts like Set name & template, Map webhook data, Paste JSON sample, Shopify order update, Add condition, and Run test:
AI Workflow Assistant panel with a chat input and shortcut buttons: Set name and template, Map webhook data, Paste JSON sample, Shopify order update, Add condition, Run test

​
Step 2: Get the webhook URL

Configure Webhook Data panel with the Webhook Callback URL, Google Sheet Instruction link, Real-time Response and Custom JSON Body tabs, and a Capture Webhook Response button
ChatSyncs generates a unique Webhook Callback URL for this workflow, e.g. https://platform.chatsyncs.com/webhook/whatsapp-workflow/xxxxxxx. Copy it — you’ll paste it into whatever external system will call it: Postman, Shopify, a custom script, or anything else that can send an HTTP request. Each workflow has its own URL, so a test request sent to it only affects this one workflow. The Real-time Response / Custom JSON Body tabs let you either capture a live test call (below) or paste a sample JSON body directly, if you don’t have a system ready to call the webhook yet.

​
Step 3: Test with Postman (or any HTTP client) and map the fields

Send a raw JSON body straight to the webhook URL — for example, from Postman:
Postman POST request to a ChatSyncs webhook workflow URL with a JSON body containing phone, customer_name, order_id, product_list, total_price, delivery_date, tracking_url, and status fields
1

Click Capture Webhook Response first

In ChatSyncs, click Capture Webhook Response before sending the test request — this is what tells ChatSyncs to start listening for the next call to this workflow’s URL.
Configure Webhook Data panel with the Capture Webhook Response button showing a Capturing Response... state
2

Send the request

With ChatSyncs still capturing, send the POST — e.g. from Postman, with a JSON body like:
3

Map the detected fields to template variables

ChatSyncs lists every field from that payload as a mappable Select Data Field dropdown, one per template variable, with an optional Select Formatter:
Webhook Response Mapping screen with Phone Number, Variable: PRODUCTLIST, Variable: TOTALPRICE, and Variable: DELIVERYDATE, each mapped to a detected field with a Select Formatter option
Match each template variable to the field it should pull from — e.g. PRODUCTLIST → product_list : Ear Buds, TOTALPRICE → total_price : 1200, DELIVERYDATE → delivery_date : 10/04/2027.
The dropdown shows a sample value, but ChatSyncs maps the field name (key), not that value. product_list : Ear Buds means “use whatever comes in under the product_list key” — not literally “Ear Buds” every time. A later request with "product_list": "Phone Case" fills the template with Phone Case automatically, with no remapping needed, as long as the field name stays the same. Only a renamed or removed field breaks the mapping.
Postman is just one option — the same capture-and-map flow works no matter what actually calls the webhook: n8n, Shopify, Cal.com, a custom script, or anything else that can send an HTTP request.

​
Worked example: it keeps working automatically

Say the template has variables for Phone Number, Customer Name, Order ID, and Delivery Date, mapped once to phone, customer_name, order_id, and delivery_date. The first test payload that taught ChatSyncs these fields might look like:
Weeks later, a completely different real customer triggers the same webhook:
Nobody touched the workflow in between. The template still fires correctly, using the new values: That’s the entire point of mapping by field name — the first webhook call only exists to teach ChatSyncs which fields are available. Every call after that just fills the same mapping with whatever values arrive:
  • Capture before you send, not after. If you send the test request first and click Capture afterward, the field list can come back empty or show data from an older, unrelated capture.
  • Body fields and header fields are listed separately. Your own JSON fields (phone, productlist, etc.) are grouped apart from the request’s technical header data (cookie, content-type, host, …) — if the mapping dropdown only shows header fields, look for the separate group with your actual payload fields.

​
Step 4: Add a delay or send conditionally (optional)

Send message with a delay section with a Wait in minutes field, and Send message based on conditions section with Any/All rule matching and an Add Rule button
Send message with a delay — set Wait to a number of minutes after the webhook triggers before the message goes out. 0 sends immediately.

​
Send message based on conditions

Instead of sending a WhatsApp message for every webhook call, conditions let you define rules that decide whether this particular call should actually trigger one. For example: send a confirmation only for paid orders, notify only once a meeting is confirmed, or trigger a message only for one specific event type, ignoring the rest.
Send message based on conditions panel with the Any/All toggle and two stacked rules, each with Select Data Field, Select Operator, and Put Value, plus an Add Rule button
Click Add Rule to add a rule — each one has three parts:
  • Select Data Field — which webhook field to check (e.g. Customer Name, Phone Number, Event Type, Meeting Status, Booking Status, Payment Status, Appointment Date, Email, Order Status, or a Custom Field). The available fields depend on what your webhook actually sends.
  • Select Operator — how to compare that field to the value you enter: Which operators show up can vary depending on the field selected.
  • Put Value — the value to compare against, e.g. Event Type Equals BOOKING_CREATED, or Payment Status Equals Paid.
Add as many rules as you need with Add Rule. Then decide how they combine:
  • Any (OR logic) — the message sends if at least one rule matches. With rules Event Type = Booking Created and Payment Status = Paid: Use Any when a single matching condition should be enough.
  • All (AND logic) — every rule must match before the message sends. With the same two rules: Use All when every requirement has to be true before sending.

​
Worked examples

  • Only confirmed meetings — one rule, Meeting Status Equals Confirmed. Result: only confirmed meetings generate a message.
  • Only paid bookings — one rule, Payment Status Equals Paid. Result: customers are notified only after payment succeeds.
  • Multiple AND conditions — mode set to All, rules Event Type Equals Booking Created, Meeting Status Equals Confirmed, Payment Status Equals Paid. Result: the message only sends when a booking is created and confirmed and paid — if any one rule fails, nothing sends.
  • Multiple OR conditions — mode set to Any, rules Event Type Equals Booking Created, Event Type Equals Booking Rescheduled. Result: the message sends for either a new booking or a rescheduled one.
Verify the webhook payload actually contains every field a rule checks, and test each condition with sample webhook data before publishing the workflow — a rule referencing a field your webhook never sends will simply never match. Keep the rule set as simple as the use case allows; it’s easier to maintain later.

​
Step 5: Configure actions after a successful call (optional)

Actions following successful webhook call section with Assign Conversation to a Group, Assign Conversation to a User, Assign Label, Remove Label, Assign Sequence, Remove Sequence, and Subscriber Name fields, and a Save Workflow button
Beyond sending the message, a successful call can also update the subscriber:
  • Assign Conversation to a Group / Assign Conversation to a User — route the conversation to a team or a specific team member.
  • Assign Label / Remove Label — tag or untag the subscriber for segmentation.
  • Assign Sequence / Remove Sequence — start or stop an automation sequence for them.
  • Subscriber Name — map a webhook field to update the subscriber’s display name in ChatSyncs.
Subscriber Name field mapped to customer_name : Rahul Reddy, boxed, above the Save Workflow button
Map Subscriber Name to the field holding the customer’s name (e.g. customer_name : Rahul Reddy) — not the phone field, which is only used to identify the subscriber. As with template variables, this maps the field name: a later call with a different customer_name value automatically updates the subscriber’s name to match. Leave it empty if your webhook doesn’t send a name — the subscriber stays identified by phone number. Click Save Workflow once everything above is configured.

​
Monitoring workflows

Webhook Workflows list under Chatbot Manager Automation, with several workflows and their Sent, Delivered, Opened, Failed, Skipped, and Unreached stats, and a Workflow Report button
The workflow list, under Chatbot Manager → Automation → Webhook Workflows, shows Sent, Delivered, Opened, Failed, Skipped, and Unreached counts for every workflow. Click Workflow Report for the full call-by-call log:
WhatsApp Webhook Workflow Report table with columns Workflow, Phone Number, Status, Response, Triggered at, Scheduled at, Response, and Webhook Data
Each row shows which Workflow it belongs to, the Phone Number the message went to, its Status (e.g. Completed), Response (e.g. Success), Triggered at / Scheduled at timestamps, and the raw Response and Webhook Data payloads — useful for confirming exactly what data a specific call sent.

​
Common use cases

  • Order confirmation — notify a customer the moment a new order event arrives.
  • Shipping updates — send tracking info when a dispatch event fires.
  • Appointment reminders — trigger from a booking system’s webhook.
  • Payment confirmation — notify once a payment event is received.
  • Lead follow-up — instantly message a new lead captured by another system.
  • Customer onboarding — welcome a new signup automatically.
  • Event registration — confirm a signup with a personalized message.

​
Best practices

  • Always include a phone field in your payload — it’s mandatory; without it ChatSyncs has no destination for the message.
  • Send phone numbers in international format (e.g. 919876543210) — this is what the webhook payload and WhatsApp both expect.
  • Keep field names consistent — the workflow maps by field name, so a renamed field breaks the mapping silently.
  • Capture before you send — click Capture Webhook Response before triggering the test call, not after, or the field list won’t reflect it.
  • Use an approved template — a workflow can’t send a template that hasn’t come back Approved from Sync Template.
  • Check the Workflow Report regularly — it’s the fastest way to spot a spike in Failed or Skipped sends.

​
Frequently asked

Create a message template with the variables you need, create a Webhook Workflow pointing at that template, copy its webhook URL into the external system (Postman, Shopify, a custom script, …), then test with Capture Webhook Response.
Click Capture Webhook Response before sending the test request, not after — ChatSyncs only detects fields from a call made while it’s actively capturing. If it still doesn’t show your fields, check that you’re looking at the payload-fields group rather than the request’s technical header data.
Yes — click Capture Webhook Response, then send a POST request to the workflow’s webhook URL from any tool (Postman, curl, a no-code automation app) with your test JSON body.
It’s a chat panel next to the workflow form that can configure the workflow for you — tell it a provider (Stripe, Shopify, etc.), paste a sample JSON payload, or use its shortcuts to set the name/template, map webhook data, or run a test, instead of doing each step manually.
Yes — every call that triggers the webhook runs the workflow again for that call’s phone number.
Open Webhook Workflow → Workflow Report and search by phone number — it shows the Status, Response, and the exact Webhook Data received for that send.
No — ChatSyncs maps by field name (the JSON key), not the sample value you saw during setup. As long as later calls use the same field names, new values fill the template automatically with no changes needed.
Yes — use Send message based on conditions to only send when a field matches a rule (e.g. status equals Confirmed), or Send message with a delay to wait a set number of minutes after the webhook triggers.
Any (OR logic) sends the message if at least one rule matches — use it when a single matching event should be enough. All (AND logic) requires every rule to match before sending — use it when every requirement has to be true, e.g. a booking that’s both confirmed and paid.
Yes — under Actions Following Successful Webhook Call, map Subscriber Name to a webhook field (e.g. customer_name), and use Assign Conversation to a Group/User or Assign/Remove Label and Assign/Remove Sequence to update the subscriber further.