Make.com (Integromat) Webhook Debugging

If you're building complex automations, chances are you've encountered webhooks. They are the backbone of real-time data exchange between applications, allowing services to communicate asynchronously. Make.com (formerly Integromat) excels at orchestrating these integrations, providing a visual builder to connect disparate systems. However, as any engineer knows, where there are integrations, there will be debugging. And when it comes to webhooks in Make.com, debugging can quickly become a significant challenge.

The visual nature of Make.com is fantastic for building, but it can sometimes feel like a "black box" when things go wrong with incoming webhooks. You might see an error in your scenario history, or worse, no execution at all, leaving you guessing about what went wrong with the incoming request. This article will dive into the nuances of debugging Make.com webhooks, highlighting common pitfalls and demonstrating how a dedicated webhook receiver like Hookpeek can provide the visibility you need to troubleshoot effectively.

Understanding Webhooks in Make.com

Make.com offers two primary ways to receive webhooks: 1. Custom Webhooks: These provide a unique URL that you can configure in any external service. Make.com automatically parses the incoming request body (usually JSON or URL-encoded form data) and makes it available as data elements in subsequent modules. 2. App-Specific Webhooks: Many Make.com app modules (e.g., Shopify, Stripe, GitHub) offer built-in webhook triggers. These are pre-configured to understand the specific payloads from those services, often simplifying the initial setup.

When a webhook hits your Make.com scenario, it attempts to process the request. If successful, you'll see an execution in your scenario history, complete with input and output bundles for each module. If it fails or doesn't trigger, that's where the real debugging begins.

Make.com's built-in tools for inspecting incoming webhook data are primarily found within the "History" tab of your scenario. For a specific execution, you can click on the initial webhook module and use the "Inspector" to see the parsed input bundle. This is helpful if the webhook was successfully received and parsed by Make.com.

Common Debugging Scenarios and Make.com's Limitations

Debugging webhook issues in Make.com often boils down to a few core problems:

  • Webhook Not Triggering: The scenario isn't executing at all. This could be due to an incorrect webhook URL, an inactive scenario, or the upstream service failing to send the webhook (or sending it to the wrong place). Critically, if Make.com doesn't "understand" the incoming request (e.g., malformed JSON, incorrect Content-Type), it might not even log an execution, leaving you blind.
  • Incorrect Data Received: The scenario triggers, but the data accessible in subsequent modules isn't what you expect. This might involve missing fields, incorrect data types, or an entirely different payload structure than anticipated. Make.com's inspector shows the parsed data, not the raw request, which can obscure issues like extra characters or incorrect headers.
  • Scenario Fails at a Later Step: The webhook is received, parsed, and the scenario starts, but a downstream module fails due to incorrect data mapping or unexpected values. While Make.com's history shows the error, understanding why the initial data led to that error can be tricky without seeing the original, raw request.

The primary limitation of Make.com's debugging capabilities for webhooks is the lack of visibility into the raw, unparsed incoming request. You see what Make.com processed, not necessarily what was sent. This distinction is crucial for diagnosing issues related to: * Malformed JSON or XML bodies. * Incorrect HTTP methods (e.g., GET instead of POST). * Missing or incorrect HTTP headers (e.g., Content-Type). * Unexpected query parameters. * Security issues like invalid signatures or missing authentication tokens.

Real-World Example 1: Debugging a Shopify Webhook

Let's say you have a Make.com scenario that triggers on a Shopify orders/create webhook. The goal is to create a new customer record in your CRM and send a Slack notification. Suddenly, your CRM isn't getting new customers, and Slack isn't pinging.

Make.com's Approach (and its Gaps): 1. You'd first check your Make.com scenario history. 2. If you see executions, you'd inspect the input bundle of the Shopify webhook module. You might find that a critical field like customer.email is missing or malformed, leading to a failure in your CRM module. 3. The Pitfall: What if there are no executions in Make.com history? This means Shopify either didn't send the webhook, or Make.com rejected it outright before logging. You have no way to see the raw request that Shopify attempted to send. You can't easily tell if the issue is on Shopify's side (e.g., network error, incorrect URL) or if Make.com silently failed to parse a malformed payload. To re-test, you'd have to create another test order in Shopify, which is time-consuming and disruptive.

Hookpeek's Approach (and why it's better): With Hookpeek, you gain complete control and visibility. 1. Configure Hookpeek as the Shopify Webhook Endpoint: Instead of pointing Shopify directly to your Make.com webhook URL, you point it to a Hookpeek URL. 2. Forward to Make.com: Within Hookpeek, you configure a "Forwarding" rule to send all incoming requests to your Make.com custom webhook URL. 3. Trigger the Webhook: Create a test order in Shopify. 4. Inspect in Hookpeek: * **