🛠️ How-to tutorials

Inbound webhooks: trigger a flow from your CRM, store or form

Updated 2026-09-19 · 4 min read · By the Convo360 team

In short

An inbound webhook trigger starts a Convo360 flow the moment an external system — your CRM, Shopify store or a website form — sends data to a unique URL the platform gives you. You map the incoming payload's fields to flow variables, secure the endpoint with a shared secret or HMAC signature, and the flow can then message the customer, notify your team or update a record automatically.

Key takeaways

An inbound webhook gives you a unique URL that any external system can call to start a Convo360 flow.
Payload mapping turns fields in the incoming JSON (like customer name or order ID) into usable flow variables.
Secure the endpoint with a shared secret or HMAC signature so only your systems can trigger the flow.
Common uses: a new Shopify order sending an instant WhatsApp confirmation, or a form fill starting a follow-up sequence.
Test with a sample payload before connecting your live system, to confirm the mapping works correctly.

Prerequisites, and what an inbound webhook trigger does

You need access to the webhook or 'notify URL' settings of the external system you're connecting (your e-commerce platform, CRM or form tool), and a rough idea of what fields that system sends in its payload (most platforms document this, or you can trigger one test event and inspect it). You'll also need a customer identifier, usually a phone number, somewhere in that payload, since the flow needs it to know who to message.

If the external system is managed by a different team, such as an e-commerce developer or a CRM administrator, loop them in early, since they'll usually be the one adding the webhook URL on their end, and having them available during your first test event saves a lot of back-and-forth later.

Most flows start because a customer messages you first. An inbound webhook flips this: it lets an external system, such as your e-commerce store, CRM, booking tool or a custom form, start a Convo360 flow programmatically, without a customer needing to send the first message. This is how 'order placed' or 'form submitted' events become instant WhatsApp confirmations, arriving within seconds of the real-world action happening.

This is a genuinely different automation pattern from everything else covered elsewhere in the Flow Builder. Keyword and group triggers still wait for something to happen inside Convo360 itself, while an inbound webhook lets an entirely separate piece of software you may not have built yourself kick off a conversation on your behalf.

Exact click path: creating the endpoint

In the Flow Builder, create a new flow and set its trigger type to Inbound webhook.
Convo360 generates a unique URL for this trigger. Copy it.
Paste this URL into your external system's webhook or 'notify URL' settings (for example, Shopify's order-created webhook, or your form tool's submission webhook).
Trigger a test event from that system, or send a sample request, to confirm the connection.

Mapping the payload to flow variables

The incoming request typically arrives as JSON: a structured set of fields like customer name, phone number, order ID and amount. In the webhook trigger's settings, map each field you need to a flow variable:

Payload field	Flow variable
customer.name	name
customer.phone	phone
order.id	order_id
order.total	order_total

Once mapped, these variables can be used anywhere downstream in the flow: in a message, a template, a condition, or written to a CRM lead or Google Sheet.

Securing the endpoint

Because a webhook URL is a public entry point, secure it so only your own systems can trigger it:

Use a shared secret: a token your external system includes in the request, which the flow checks before proceeding.
Where supported, use an HMAC-signed payload, which cryptographically verifies the request genuinely came from your system and wasn't tampered with.

Never share a live webhook URL publicly, and rotate the secret if you suspect it has leaked. Treat a webhook secret with the same care as a password. Anyone who obtains it could send fabricated events that trigger flows and message your real customers, so avoid pasting it into chat messages, tickets or shared documents where it could be copied by mistake.

Two worked examples

Shopify order confirmation: a new order fires the webhook, the flow maps customer name, order ID and total, then immediately sends a WhatsApp confirmation with an approved Send Template block, followed by a delivery-tracking flow later. A D2C brand in Bengaluru using this cut the time between an order landing and the customer getting a confirmation from hours (whenever staff checked the order dashboard) down to seconds.
Website form fill: a lead form submission fires the webhook, the flow captures name, phone and enquiry type, saves it via Save CRM lead, and starts a WhatsApp follow-up conversation within minutes instead of waiting for a team member to call back.

Troubleshooting common issues

Issue	Fix
Webhook never fires	Confirm the URL was pasted correctly into the external system, with no extra spaces or truncation.
Flow fires but variables are empty	Check the payload field names match exactly what the external system actually sends. Inspect a real test payload rather than assuming the field names from documentation.
Requests are being rejected	Check the shared secret or HMAC signature configuration matches on both sides exactly.
Duplicate messages sent for one event	Some systems retry webhook delivery on a slow response. Confirm your flow responds quickly and doesn't re-trigger unintentionally.

Testing before going live

Send a sample JSON payload to your webhook URL using a testing tool, or trigger a genuine test event (a test order, a test form submission) from the connected system.
Check Flow Logs to confirm the trigger fired and the variables mapped correctly.
Run Preview / Try-it on the rest of the flow to confirm the customer-facing messages look right with real data filled in.
Only then point your live system at the webhook URL.

It's worth keeping this test event and its logged result on hand even after going live. The next time you troubleshoot a mapping issue, having a known-good example to compare against a failing one saves a lot of guesswork about which field changed or went missing.

Step by step

Identify the payload fields you needCheck your external system's documentation or trigger a test event to see the actual field names.
Create the inbound webhook triggerSet a new flow's trigger type to Inbound webhook and copy the generated URL.
Add the URL to your external systemPaste it into the relevant webhook or notify-URL setting in your CRM, store or form tool.
Map payload fields to flow variablesConnect fields like customer name and order ID to variables you'll use in the flow.
Secure the endpointAdd a shared secret or HMAC signature so only your systems can trigger it.
Send a test eventTrigger a real or sample event and check Flow Logs to confirm correct mapping.
Go livePoint your live system at the webhook URL only after testing succeeds.

Example conversation

(system: Shopify order #4521 placed, webhook fires automatically)

Hi Meera, thanks for your order #4521 (₹2,349) from Ridhi Sidhi Boutique! We're packing it now — you'll get a tracking link here as soon as it ships.

Connect your systems free for 14 days

Start free in minutes — no code, no credit card. Bring your own AI keys and pay no per-message markup.

Start 14-day free trial →See pricing

Frequently asked questions

Do I need a developer to set up an inbound webhook?

Setting up the trigger and mapping fields is done visually in Convo360's Flow Builder. You may need basic help finding the webhook settings in your CRM or store platform, but no custom code is required on the Convo360 side.

Is a webhook trigger secure against random requests?

Yes, when configured with a shared secret or HMAC signature, which the flow checks before processing the request — this blocks unauthorised calls to your webhook URL.

Can a webhook trigger send a WhatsApp message immediately?

Yes, once the flow is triggered and variables are mapped, it can send a message right away, though if it's been more than 24 hours since the customer last messaged you, the message needs to use an approved template.

What happens if the incoming payload is missing a field?

The corresponding flow variable will be empty, so it's worth adding a Condition check for critical fields, or a fallback message, in case an external system sends incomplete data.

Can I use one webhook for multiple types of events?

It's generally cleaner to use separate webhook triggers for distinct event types (e.g. order placed vs order cancelled), each with its own mapping, rather than combining several event types into one.

How do I debug a webhook that isn't triggering the flow?

Check Flow Logs first to see whether the request even arrived — if it didn't, the issue is usually the URL or the external system's configuration; if it arrived but the flow didn't run correctly, the issue is usually a field mapping mismatch.