🇪🇸 Español 🇬🇧 English 🇧🇷 Português
Guides

Trigger a workflow from your ecommerce or ERP with an inbound webhook

Connect your store or ERP to Omnifox: an inbound webhook with path_match order.paid fires templates, tasks and HTTP calls back.

July 11, 2026

Your ecommerce already knows when someone pays, your ERP knows when an order changes. The question is: how do you turn that event into a WhatsApp message, a task for the team or a contact update without building a whole integration. The answer is the Inbound webhook trigger in Omnifox workflows. You hand a URL to your external system, each event arrives as JSON, and you decide what to do with it. In this guide we build it step by step.

The trigger: Inbound webhook

Every workflow starts with a single trigger. Here we pick Inbound webhook. Omnifox gives you a unique URL; you paste it into your store (Shopify, WooCommerce, your homegrown ERP) as the destination for its webhooks. Every time that system fires an event, your workflow runs.

The key is the path_match filter: an expression that decides whether the payload is relevant, for example event.type == "order.paid". That way one endpoint can receive many event types and each workflow reacts only to its own (payment confirmed, order shipped, refund, and so on).

Step 1: read the payload

The webhook body is available as {{$webhook.payload}}. You can navigate its fields (customer email, total, order number) and drop them into downstream nodes. A good first node is Set variable to pull out the data you will reuse several times (like the order number) and give it a short, readable name.

If the event carries the customer phone or email, add Find previous conversation to reuse the existing thread instead of opening a new one. That way the customer gets the notification in the same conversation where they already talk to you.

Step 2: branch by event type

If your path_match already filtered tightly, you may not need to branch. But if you let several events through, a Switch (multiple branches) node lets you open one branch per type: payment, shipping, cancellation. You can also use If (single rule) for binary cases, like "if the amount is over X, treat it as a VIP order".

The skeleton looks like:

  1. Inbound webhook with path_match: event.type == "order.paid" (trigger)
  2. Set variable (order number, total)
  3. Find previous conversation (reuse the customer thread)
  4. Switch (by event type, if applicable)

Step 3: notify the customer with a template

Because the trigger comes from an external system and not from a customer message, you are very likely outside WhatsApp's 24-hour window. So the right node is Send WhatsApp template. Pick an approved template like "Your payment is confirmed" and inject payload variables: order number, amount, estimated delivery date, {{$contact.first_name}}.

If the customer is on a channel with no window (email, for instance), you can use Send email to customer instead.

Step 4: create internal work

A confirmed payment almost always spawns work. Add Create follow-up task so an agent prepares the shipment, or Create card from conversation to move the order onto a fulfillment board. You can chain Update contact to mark the customer as a buyer or bump their lifecycle stage.

Step 5: respond to the external system

Sometimes you need to confirm something back to your ERP: mark the order as "notified", request the shipping label, sync inventory. That is what the HTTP request node is for; it calls any external API with the method, headers and body you define, using the variables you extracted. Wrap it in a Try/Catch so an external API error does not take down the whole workflow.

Full example flow

Inbound webhook (order.paid) -> Set variable -> Find previous conversation -> Send WhatsApp template -> Create follow-up task -> HTTP request (mark as notified) inside Try/Catch

Common mistakes

  • path_match too broad. If you do not filter, your workflow fires on every event and sends extra messages. Be specific: event.type == "order.paid".
  • Assuming a WhatsApp window exists. The webhook is not from the customer; use Send WhatsApp template, not Send message.
  • Not wrapping HTTP request in Try/Catch. A downed external API should never break the customer notification.
  • Forgetting unknown variables. If a payload field does not exist, it resolves to an empty string; verify the exact names.

Variants

  • Dump each order to Google Sheets (append row) for a simple, shareable log your finance team can audit.
  • Use Create deal if the payment opens a larger sales cycle, then Assign deal owner so a rep follows up on the upsell.
  • Combine with the Scheduled (cron) trigger in another workflow to retry failed notifications or reconcile orders overnight.
  • Add Add tag on the contact (for example paid-customer) so downstream workflows and segments know this person already bought.

An inbound webhook turns Omnifox into the notification brain of your operation: your ecommerce fires, Omnifox translates that event into messages, tasks and calls back out. Copy the URL, paste it into your system and start automating today.

Comentarios (0)

Todavía no hay comentarios. Sé el primero en compartir tu opinión.

Dejá un comentario

Tu email nunca se publica. Los comentarios se moderan antes de aparecer.

Soporta markdown. El HTML se elimina.