Help Integrations How Do I Set Up Incoming Webhooks

Incoming webhooks are automated connections that allow external services to send real-time data directly into your system by making HTTP POST requests.

Austin Beveridge

Tennessee

, Goliath Teammate

Incoming webhooks are automated connections that allow external services to send real-time data directly into your system by making HTTP POST requests to a unique URL endpoint you control. Setting up incoming webhooks involves generating a webhook URL in your application, configuring the external service to send data to that URL, and validating incoming requests to ensure security and reliability. This guide walks you through the complete process of implementing incoming webhooks in most modern platforms.

TL;DR

  • Create a webhook endpoint by obtaining a unique URL from your application's settings, usually found under integrations or API sections.

  • Configure the external service with your webhook URL and specify which events should trigger data to be sent to you.

  • Validate incoming webhook requests using signature verification and basic security checks before processing the data.

Understanding Webhooks and How They Work

A webhook is essentially a way for one application to push data to another application in real time. Unlike traditional API calls where you request data, webhooks work the opposite way: the external service watches for events and sends you the data automatically when those events happen. For example, when a payment is processed, a form is submitted, or a file is uploaded, the external service can immediately notify your system by sending a POST request to your webhook URL.

The flow works like this: An event occurs in an external service (like a payment processor, CRM, or form builder). That service then makes an HTTP POST request to the webhook URL you've provided. Your application receives this request, processes the data, and performs whatever action you've configured (storing information in a database, triggering a workflow, sending a notification, etc.). Your application responds with a success status code, confirming the webhook was received.

Webhooks are superior to polling (repeatedly asking for new data) because they're immediate, efficient, and reduce server load. The external service only sends data when something actually changes, rather than you constantly checking for updates that don't exist.

Step 1: Access Your Webhook Settings

Most modern platforms provide a dedicated section for managing integrations and webhooks. The exact location varies by platform, but follow these general principles to find it.

Log into your account and look for sections labeled "Integrations," "API," "Webhooks," "Settings," or "Developer Tools." This is often found in your account dashboard under a gear icon or in the main navigation menu. Some platforms nest it under "Advanced Settings" or "Connections." If you can't find it immediately, check your platform's help documentation for "webhook setup" or "incoming webhooks" and search by your specific platform name.

Once you locate the webhooks section, look for an option to create or add a new webhook. You should see a button labeled "New Webhook," "Add Integration," "Create Webhook," or something similar. Click this to begin the setup process.

Step 2: Generate and Copy Your Webhook URL

When you initiate webhook creation, your system generates a unique URL endpoint specifically for receiving data. This URL is yours alone and acts as a secure mailbox for incoming data from external services. It typically follows a pattern like "https://yourplatform.com/webhooks/abc123def456" or "https://api.yourplatform.com/incoming/xyz789."

Copy this URL exactly. Most platforms provide a copy button next to the URL field. Keep this URL secure and do not share it publicly. Anyone with this URL could theoretically send data to your webhook endpoint, so treat it like a private key. Some platforms allow you to regenerate the URL if it's been compromised.

Some platforms also provide a webhook signing key or secret token at this stage. If one is generated, copy and store this securely as well. You'll use this to verify that incoming requests actually came from the external service, not from someone spoofing the webhook URL.

Step 3: Configure the External Service with Your Webhook URL

Now you need to tell the external service where to send its data. Log into the external service (the payment processor, CRM, form builder, or whatever application is sending you data), and navigate to its integrations or webhooks settings. Find the option to add a new webhook or integration.

Paste your webhook URL into the designated field. The external service will typically ask you which events should trigger a webhook delivery. For example, a payment processor might let you choose between "payment received," "payment failed," "refund processed," and other events. Select the events that matter to your use case. If you're unsure which events you need, start with the most important ones and add more later.

Some services let you customize the data format or payload. If you have this option, review what data fields will be sent to you and ensure they're useful for your workflow. You may also see options for retries (how many times the service will attempt to send the webhook if your endpoint doesn't respond), timeouts, and other reliability settings. Leave these at their defaults unless you have specific requirements.

After configuring these settings, save or activate the webhook. The external service is now configured to send data to your system.

Step 4: Test the Webhook Connection

Before considering the webhook fully operational, test it to ensure the data is flowing correctly. Many external services provide a "Send Test Webhook" or "Send Sample" button in their webhook management interface. Click this to send a test payload to your webhook URL.

Return to your platform's webhook management page and check whether the test webhook was received. Most platforms display a log or event history showing all incoming webhooks with timestamps, payloads, and delivery status codes. If you see the test webhook listed with a success status code (usually 200 or 201), the connection is working.

If the test webhook doesn't appear or shows a failure status, troubleshoot by checking the following: Verify you copied the webhook URL correctly with no typos or extra spaces. Confirm the external service is using the correct URL. Check if your platform requires you to whitelist IP addresses from the external service. Review any error messages or response codes in the webhook logs. Contact the external service's support team if the issue persists on their end.

Step 5: Validate Incoming Webhook Requests

A critical security step is validating that incoming webhooks actually came from the external service you're expecting, not from a malicious source. The external service should send a signature or token with each webhook request, either as a header or in the request body.

When you receive a webhook, extract this signature from the request headers. Most services send it as an "X-Webhook-Signature," "X-Signature," or similar header. Take the signing key or secret token that was provided when you created the webhook, combine it with the raw request body using a hashing algorithm (typically HMAC-SHA256), and verify that your calculated hash matches the signature sent by the external service.

If the signatures match, the webhook is legitimate. If they don't match, reject the request and log it as a potential security issue. This validation process prevents unauthorized users from sending fake data to your webhook endpoint.

Beyond signature verification, implement additional security measures: Always use HTTPS (never HTTP) for your webhook URL. Log all incoming webhooks for debugging and audit purposes. Implement rate limiting to prevent a single source from overwhelming your system with requests. Respond quickly to webhook requests (within 5-10 seconds) so the external service doesn't retry unnecessarily.

Step 6: Process and Act on Webhook Data

Once you've verified that a webhook is legitimate, your system needs to process the data and take action. The specific action depends on your use case, but common examples include storing the data in a database, triggering a workflow or automation, sending a notification to users, updating a record in another system, or logging the event.

Make sure your webhook handler is idempotent, meaning it can safely process the same webhook multiple times without causing problems. The external service may retry sending the webhook if it doesn't receive a success response, so your code should handle duplicate requests gracefully. A common approach is to store the webhook's unique identifier (many services include an ID in the payload) and check if you've already processed it before taking action.

After processing the webhook, respond to the external service with a 2xx success status code (200 OK or 201 Created). This tells the external service that you received and processed the data successfully, and it won't retry. If something goes wrong, respond with an appropriate error code (4xx or 5xx) so the service knows to retry.

Monitoring and Maintaining Your Webhooks

After setup is complete, regularly monitor your webhook's health. Most platforms provide a dashboard showing webhook delivery success rates, recent deliveries, and any failures. If you notice failed deliveries, investigate the cause: Check your endpoint's uptime. Verify that the external service hasn't changed its webhook format or signing method. Look for error messages in your application logs. Contact the external service's support team if the issue is on their end.

Test your webhooks periodically to catch connection issues before they impact your business. Set up alerts for webhook failures so you're notified immediately if something breaks. Document which webhooks you've set up and what they do, especially if multiple team members manage integrations.

Common Webhook Setup Mistakes to Avoid

Don't skip the signature validation step thinking it's unnecessary. Without verification, you expose yourself to data injection attacks. Don't leave your webhook URL in your code comments or documentation where it might be accidentally shared. Don't assume your webhook endpoint is always available; implement retry logic on the external service side if possible. Don't ignore webhook logs and monitoring; issues often go undetected for weeks if you're not watching. Don't hardcode the webhook URL; use environment variables so you can change it between development, testing, and production environments without code changes.

Frequently Asked Questions

What's the difference between incoming webhooks and outgoing webhooks?

Incoming webhooks receive data from external services into your system, while outgoing webhooks send data from your system to external services. When you're setting up incoming webhooks, you're creating an endpoint that listens for data. If you wanted to send data out to another service, you'd be setting up outgoing webhooks, which typically involve configuring your system to make HTTP requests to external URLs when certain events happen.

Can I use the same webhook URL for multiple external services?

Technically yes, but it's generally not recommended. Using separate webhook URLs for each external service makes it easier to manage, debug, and monitor integrations. It also provides better security since you can verify the signature differently for each service. If you must use a shared endpoint, ensure your validation logic can distinguish between different sources and process their payloads differently.

How long does a webhook have to be processed before timing out?

Most external services expect a response within 5 to 30 seconds, though this varies by platform. Check your specific external service's documentation for their timeout window. If your webhook processing takes longer than the service's timeout, the service will assume the delivery failed and retry. To handle slow processing, immediately respond with a success code, then process the data asynchronously in the background.

What should I do if I stop receiving webhooks from a service?

First, verify your webhook endpoint is online and responding to requests. Check your webhook logs to see if deliveries are being attempted. Confirm the external service hasn't updated its signing method or webhook format. Review any error codes or messages in the service's integration logs. Finally, resend a test webhook from the external service to confirm the connection is working. If problems persist, contact the external service's support team.

Sources