Webhook Workflows: Automating Business Processes with Custom Code

Back to Blog

Every time a customer fills out your contact form, someone on your team manually copies the information into your CRM. When a payment comes through Stripe, someone logs it in your spreadsheet. When an order ships, someone sends a confirmation email by hand. These small manual tasks add up to hours of repetitive work every week, and each one is an opportunity for human error.

Webhooks eliminate the manual step. They’re the plumbing that connects your business tools and triggers automated actions the instant something happens. A form submission automatically creates a CRM contact. A successful payment triggers an invoice email. A shipping update sends a tracking notification. No human intervention, no delays, no mistakes. This post covers one piece of a bigger system, and we mapped out the rest in the guide to custom web applications for small business owners.

Most businesses use tools that support webhooks without realizing it. The missing piece is the custom code that receives those webhooks and turns them into meaningful automated workflows. We build webhook-powered automation for small businesses that want their systems to talk to each other without manual effort. Here’s how webhooks work and what you can automate with them.

Webhooks vs. Polling: Why Webhooks Win

There are two ways for systems to share information: polling and webhooks. Understanding the difference matters because it affects reliability, speed, and cost.

Polling

Polling means your system repeatedly checks another system for new data. Every 30 seconds, or every 5 minutes, or every hour, your code asks: “Anything new?” Most of the time, the answer is “No,” and the request was wasted.

Problems with polling:

Delays. If you poll every 5 minutes, events can be up to 5 minutes old before you process them.
Wasted resources. Most requests return no new data, but each one consumes API rate limits, bandwidth, and server resources.
Rate limiting. Many APIs limit how often you can check. Frequent polling can hit those limits and get your requests blocked.
Scaling issues. If you’re monitoring 100 different resources, that’s 100 polling requests per interval.

Webhooks

Webhooks flip the model. Instead of you checking for new data, the source system sends you a notification the instant something happens. Your system sits idle until it receives an event, then processes it immediately.

Advantages of webhooks:

Real-time. Events are processed within seconds of occurring.
Efficient. Your server only does work when there’s work to do.
No rate limit concerns. You’re not making requests; you’re receiving them.
Scalable. One webhook endpoint can handle events from thousands of sources.

The tradeoff is that webhooks require you to have a publicly accessible endpoint ready to receive incoming requests. This means running a server or using a serverless function that’s always available.

How Webhooks Work

A webhook is a URL on your server that another service sends data to when an event occurs. The mechanics are simple:

You register a webhook URL with the source service (e.g., Stripe, your form provider, your CRM)
You specify which events you want to be notified about
When an event occurs, the source service sends an HTTP POST request to your URL with event data in the body
Your server receives the request, processes the data, and returns a success response
If your server doesn’t respond (or returns an error), the source service retries the delivery

The data payload is typically JSON and contains everything you need to know about the event: what happened, when, to whom, and all the relevant details.

Dashboards and portals turn scattered data into one source of truth.

Common Webhook Use Cases

The real power of webhooks emerges when you connect them to business logic. Here are the workflows we build most often for small businesses.

Stripe Payment Webhooks

Stripe’s webhook system is one of the most robust available. It covers the entire payment lifecycle:

payment_intent.succeeded – A payment was completed successfully. Trigger order fulfillment, send a receipt, update your internal records.
payment_intent.payment_failed – A payment attempt failed. Send a notification to the customer with instructions to update their payment method.
customer.subscription.created – A new subscription was started. Provision access, send a welcome email, notify your team.
customer.subscription.updated – A subscription plan changed. Adjust feature access, send a confirmation.
customer.subscription.deleted – A subscription was canceled. Revoke access, send a retention offer, log the cancellation reason.
invoice.payment_failed – A subscription renewal payment failed. Trigger dunning emails, flag the account.
charge.dispute.created – A customer filed a chargeback. Alert your team immediately for response.

A typical Stripe webhook workflow for a subscription business:

Webhook receives invoice.paid event
Look up the customer in your database
Extend their subscription access period
Generate and send an invoice PDF
Log the payment in your reporting system
Update the customer’s record in your CRM

All of this happens within seconds of the payment processing, with zero manual intervention.

Form Submission Webhooks

Contact forms, quote request forms, and application forms can trigger webhooks that automate the follow-up process:

CRM contact creation. When someone submits a form, automatically create a contact record in your CRM (HubSpot, Salesforce, Pipedrive, etc.) with all the form data.
Team notifications. Send a Slack message or email to the appropriate team member based on the form type or inquiry topic.
Auto-responder emails. Send a personalized confirmation email immediately, not a generic “we received your message” but one that references what they asked about.
Task creation. Create a follow-up task in your project management tool (Asana, Trello, Monday.com) assigned to the right team member.
Lead scoring. Analyze the form data and assign a lead score based on criteria like service type, budget range, or location.

CRM and Sales Webhooks

CRM systems trigger webhooks when records change, enabling automation throughout your sales pipeline:

Deal stage changes. When a deal moves to “Proposal Sent,” automatically generate and send the proposal document.
Contact updates. When a contact’s status changes to “Customer,” trigger onboarding workflows.
Activity logging. When a call or meeting is logged, update related systems and send follow-up materials.
Win/loss notifications. When a deal is won or lost, notify relevant team members and update reporting dashboards.

E-Commerce Order Webhooks

Online stores generate webhooks throughout the order lifecycle:

Order placed. Update inventory, send confirmation email, create shipping label, notify warehouse.
Order shipped. Send tracking information to the customer, update the order status on your website.
Order delivered. Send a review request email, trigger a satisfaction survey.
Refund processed. Update inventory, send refund confirmation, adjust financial records.

Scheduling and Appointment Webhooks

Booking tools like Calendly, Acuity, and custom scheduling systems support webhooks:

Appointment booked. Send confirmation to both parties, create a calendar event, send preparation materials.
Appointment canceled. Open the slot back up, send a cancellation confirmation, trigger a rebooking email.
Appointment rescheduled. Update calendar events, send updated confirmations.
Reminder triggers. Send reminders at configured intervals before the appointment.

Building Reliable Webhook Handlers

Webhook handlers need to be more reliable than typical web endpoints. When a webhook fails silently, business processes break without anyone noticing. Here’s how to build handlers that work consistently.

Respond Quickly

Webhook senders expect a response within a few seconds (Stripe’s timeout is 20 seconds). If your handler takes too long, the sender marks the delivery as failed and retries. This can cause duplicate processing.

The solution is to separate receiving from processing:

Receive the webhook and immediately return a 200 response
Place the event in a queue (database table, message queue, or job queue)
Process the event asynchronously from the queue

This pattern ensures fast response times regardless of how complex the processing is.

Verify Signatures

Every webhook from a reputable service includes a signature in the request headers. This signature is generated using a secret key shared between you and the sender. Your handler should verify this signature before processing any webhook data.

Without signature verification, anyone who discovers your webhook URL can send fake events. An attacker could trigger fake payment confirmations, create fake orders, or manipulate your business data.

Stripe, Square, PayPal, GitHub, and most other services provide signature verification in their SDKs. Use them. Never skip this step.

Handle Retries and Idempotency

Webhook senders retry failed deliveries. If your handler processed an event but crashed before returning a 200 response, the sender will redeliver it. Your handler must be idempotent, meaning processing the same event twice produces the same result as processing it once.

Strategies for idempotency:

Store processed event IDs. Before processing an event, check if you’ve already processed an event with that ID. If so, skip it and return success.
Use database transactions. Wrap your processing logic in a transaction so it either completes fully or rolls back entirely.
Idempotent operations. Design your actions to be naturally idempotent. “Set status to active” is idempotent. “Increment balance by $50” is not. Use the former pattern when possible.

Log Everything

Comprehensive logging for webhooks is essential:

Log the raw payload. Store the complete webhook data for debugging and auditing.
Log processing steps. Record what your handler did with the event.
Log outcomes. Record whether processing succeeded or failed, and why.
Log timing. Track how long processing took to identify performance issues.

When something goes wrong (a customer claims they paid but weren’t credited, an order wasn’t fulfilled), your webhook logs should provide a complete timeline of events.

Handle Failures Gracefully

When webhook processing fails, you need a recovery plan:

Retry logic. If processing fails due to a temporary issue (database unavailable, external API down), queue the event for retry.
Dead letter queue. After multiple retries fail, move the event to a dead letter queue for manual investigation.
Alerting. Set up alerts for webhook processing failures. A spike in failures often indicates a systemic issue that needs immediate attention.
Manual replay. Build the ability to manually replay failed events once the underlying issue is fixed.

Architecture Patterns

Serverless Webhook Handlers

For businesses that don’t want to manage a dedicated server, serverless functions (AWS Lambda, Vercel Functions, Cloudflare Workers) are excellent for webhook handling:

Always available. Serverless functions spin up on demand, so your endpoint is always ready.
Auto-scaling. If you receive a burst of webhooks, serverless functions scale automatically.
Low cost. You only pay for actual invocations, not idle server time.
No infrastructure management. No server patches, no uptime monitoring, no capacity planning.

Webhook Aggregation

If you receive webhooks from many sources (Stripe, forms, CRM, scheduling), consider routing them through a single aggregation layer:

All webhooks hit a central endpoint
The aggregator identifies the source and event type
The event is routed to the appropriate handler
Common concerns (logging, signature verification, idempotency) are handled in one place

This pattern simplifies monitoring and debugging because all webhook activity flows through a single system.

Testing Webhook Integrations

Testing webhooks requires simulating events from external services:

Stripe CLI. Stripe provides a CLI tool that forwards webhook events to your local development server. You can trigger test events for any event type.
ngrok or similar tunneling tools. Expose your local server to the internet temporarily so external services can send webhooks to your development environment.
Webhook testing services. Tools like Webhook.site let you inspect incoming webhook payloads to understand their structure before building handlers.
Mock events. Build a library of sample webhook payloads for each event type you handle. Use these for automated testing.