How to Set Up Webhook Automations Between Your Business Apps

Every business owner who has paid attention for more than a year knows the feeling. You buy a tool to do one job. The tool is great at the one job. Then you realize that to actually run your business, this tool needs to talk to the four other tools you already have, and exactly zero of them have a native integration with each other.

This is where most operators reach for the cheap glue. They hire a virtual assistant to copy-paste from one app to another. They build a Zapier flow with seven steps and 90 second execution time, which is fine until a step times out at 3 AM and breaks a chain you cannot debug.

Webhooks are the better option, and they are not as scary as the name suggests. This post walks through what a webhook actually is, when it is the right tool versus when a native integration is, the four-step setup that takes about an hour the first time and ten minutes every time after, and the specific SMB use cases that pay for themselves the day you ship them.

A webhook is an HTTP callback. App X has an event it cares about (a new customer was created, a payment failed, a form was submitted). When that event happens, App X sends a small package of data — the event payload — to a URL you have specified. The URL belongs to App Z. App Z receives the package, parses it, and does something with it.

That is the entire mechanic. Three parts: a source app, an event, and a receiver URL. The metaphor that helped me when I first internalized this is a doorbell. The doorbell has a button (the event). When somebody presses the button, the bell rings somewhere else (the receiver). The wire between them is the webhook.

The practical implication is that any two apps that both speak webhook can be connected even if neither one has heard of the other. Stripe does not know your CRM exists. Your CRM does not know Stripe exists. But Stripe can fire a webhook whenever a new customer subscribes, and your CRM can listen on a URL for that webhook, and now they talk to each other.

The rule is simple: use the native integration if it exists and does what you need. Use a webhook to fill the gaps.

Native integrations are better when they are available because the provider has done the work of mapping fields, handling auth refreshes, and managing failures. You click connect, you trust the engineering on the other end, you move on. The tradeoff is that native integrations only cover the use cases the provider decided were popular enough to support. If you want a specific behavior they did not anticipate, you are stuck.

Webhooks are the right tool when one of three things is true. First, no native integration exists between the two apps. Second, the integration exists but is too coarse — for example, the native Stripe-to-HubSpot integration syncs customers but not the metadata field you specifically need. Third, you want to insert business logic between the apps that neither side knows about, like "only sync this Stripe customer to CRM if the plan value is greater than $99/mo."

In Deelo, the Automation app is designed to be the orchestration hub for both directions. It can receive webhooks from any external app as a workflow trigger, and it can fire outbound webhooks to any external URL as a workflow action. That means Deelo can sit in the middle of any webhook-to-webhook bridge, adding filters, transformations, and conditional logic between the two ends.

Every webhook integration follows the same four steps. Once you have done it once, the second one takes ten minutes. The friction is entirely in the first one, which is the universal experience.

Open the source app's settings. Look for a Webhooks, Developers, or Integrations section — every modern SaaS has one buried somewhere. Find the list of events the app can broadcast. In Stripe, this is in Developers > Webhooks > Events. In Calendly, it is under Integrations > Webhooks. In Typeform, it is in the form's Connect tab.

Figure out the exact event name you need. Stripe's event names are dotted strings like `customer.created`, `invoice.payment_succeeded`, `customer.subscription.deleted`. Calendly has `invitee.created` and `invitee.canceled`. Typeform has `form_response`. Read the event documentation in the source app to confirm the payload shape — what fields will arrive, what they are named, what types they are. This is the most boring step and the one most people skip, which is why their webhooks break in production two weeks later when they discover a field is nullable when they assumed it was always populated.

In Deelo, this is the easy part. Open the Automation app, create a new workflow, choose `webhook.received` as the trigger. Deelo generates a unique URL for that workflow — something like `https://your-org.deelo.app/api/webhooks/{{workflowId}}`. Copy this URL.

If you are sending to a different receiver app entirely, get its inbound webhook URL from its integrations section. Make sure the URL is HTTPS, not HTTP, because most modern source apps refuse to send to plaintext endpoints.

Back in the source app, paste the receiver URL into the webhook configuration. Most apps will let you choose which events to subscribe to — pick only the ones you actually need, not every event the app offers, or you will get a flood of irrelevant traffic that you have to filter later.

In the receiver workflow (Deelo Automation, in our case), add transformation steps that map the incoming payload fields to whatever the next action expects. For example, Stripe's `customer.created` event has the customer email at `data.object.email`. If your next step is to create a CRM contact, the CRM expects a field called `email`. Set the mapping explicitly: `email = data.object.email`. Do this for every field. Don't trust auto-mapping — it works until it doesn't.

Add a signature verification step if the source app supports webhook signing (Stripe does, Twilio does, most security-conscious apps do). The source app signs the payload with a shared secret, and your receiver verifies the signature before processing. This prevents an attacker from sending fake webhooks to your endpoint and creating fake customers in your CRM. In Deelo, signature verification is a built-in option on the webhook trigger — supply the signing secret from the source app's webhook settings, and the workflow will reject any payload with a bad signature.

Trigger the source event manually with a single test record. Most modern apps have a "Send test event" button in the webhook settings — Stripe, Calendly, Typeform all do. The test sends a fake payload to your receiver URL.

Verify it arrived. In Deelo, open the workflow's Run History and confirm a run was created with the test payload, every transformation step succeeded, and the downstream action (creating the CRM contact, or whatever) happened. If any step failed, the run history shows exactly which one and why.

Once the single test works, send a few real events through. Watch the run history for the first 24 hours. Watch the error rate. If you see retries or failures, the most common cause is a field you assumed was always present being null in some real events. Fix the transformation logic, redeploy, watch again.

The non-negotiable part of monitoring is alerting on failure. Webhooks fail silently by default — if the receiver is down or the payload is malformed, the source app might retry a few times and then give up. In Deelo, configure the workflow's `onFailure` handler to send a notification to Slack or email when a run fails. You do not want to discover three weeks later that you have been missing 8% of your webhook events.

Networks fail. Receivers are temporarily down. Rate limits get hit. The webhook setup is not complete until you have thought about what happens when the call does not succeed on the first try.

Most source apps have their own retry logic. Stripe retries failed webhooks with exponential backoff over three days. Twilio retries for up to 24 hours. Calendly retries five times. The source app retry is the first line of defense.

On the receiver side, build idempotency. The same event might arrive twice — once from the source's first attempt, and again from a retry if the source did not get a clean 200 OK response. Every incoming webhook should have a unique event ID in its payload (Stripe puts it in `id`, Calendly in `event.payload.uuid`). Store the IDs you have already processed and skip duplicates. In Deelo, the workflow trigger has a built-in `dedupeOn` field — set it to the event ID path and duplicates are dropped automatically.

For outbound webhooks (Deelo firing to an external receiver), the Automation app has retry built in. Configure the retry policy on the `webhook.send` action: max attempts, backoff strategy, and a dead-letter handler that catches anything that fails all retries. The dead-letter handler can email the owner, write to a CRM task, or whatever surfaces the failure for human attention.

Four use cases that pay back the setup time within the first week of running.

Webhooks have a complexity ceiling. If you are building a chain that involves five apps, four transformations, conditional branching, and shared state across runs, you are reinventing a workflow engine. Stop. That is what the Automation app is for. Use webhooks as the entry and exit points; let the workflow engine handle the orchestration in the middle.

The other limit is high-volume real-time data. Webhooks are great for events that fire at human scale — new customer, new booking, payment failed. They are not the right tool for streaming data, where you might have thousands of events per second and you actually want a message queue or a streaming pipeline.

For 95% of SMB use cases, you are nowhere near these limits. The four-step setup above is enough to wire up the integrations that actually move revenue. Pick the highest-leverage one from the use case list. Spend an hour this week. Watch what it does to the number of things that fall through the cracks in your business by the end of the month.