Make.com 101

Make.com is visual automation. You connect triggers to actions, and data flows between services automatically. It is the glue that holds your stack together — and it replaces thousands of lines of integration code you would otherwise write by hand.

Why Visual Automation Matters

Every modern stack has a dirty secret: most of the code is integration glue. Connecting Stripe to your database, sending Slack notifications when someone subscribes, syncing spreadsheets with analytics — none of this is your product, but it can consume 40% of your development time.

Make.com eliminates that glue code. Instead of writing a custom webhook handler for every service connection, you drag modules onto a canvas, map data fields between them, and hit "Run." The scenario runs on Make.com's infrastructure — no servers, no deployment, no maintenance.

🧩

1,600+

App integrations available in Make.com — from Stripe to Notion to GitHub

⚡

Zero Code

Visual canvas replaces custom integration scripts and webhook handlers

💰

1,000 Free

Operations per month on the free tier — enough for most indie projects

Anatomy of a Scenario

A Make.com scenario is a chain of modules. Each module does exactly one thing: watch for an event, transform data, or send it somewhere. Modules execute left to right, passing data downstream like a conveyor belt.

Every scenario has three parts:

Trigger — What Starts It

Either a Webhook (fires when an external service sends data) or a Schedule (fires on a timer — every hour, every day at 9am, etc.). The trigger is always module #1.

Processing — What Happens

Modules that transform, filter, or route data. Filter modules apply conditional logic (only continue if amount > $50). Router modules split the flow into parallel paths. Iterator modules loop over arrays.

Output — What It Produces

The final module sends data somewhere: Supabase (insert a row), Slack (post a message), Resend (send an email), Google Sheets (log a row). Most scenarios end with 1-3 output modules.

Three Real Scenarios (Production-Tested)

These are not hypothetical examples — they represent the exact patterns used in production AI stacks. Each one replaces 50-100 lines of custom integration code.

Scenario 1: Email Capture Pipeline

Webhook (Trigger) → Resend (Send Welcome) → Supabase (Insert Row) → Slack (Notify #growth)

When someone subscribes on your site, the webhook fires. Resend sends a branded welcome email. Supabase stores the subscriber with a timestamp. Slack notifies your team. Total time: under 2 seconds. Zero code.

Scenario 2: Content Publishing Autopilot

Schedule (Every Day 9am) → Supabase (Get Draft) → Claude (Polish Copy) → CMS (Publish Post) → Twitter (Post Thread)

Every morning, grab a draft from your content queue, have Claude refine the copy, publish to your CMS, and auto-post a Twitter thread. This turns a 30-minute daily task into a fully autonomous pipeline.

Scenario 3: Revenue Alert System

Stripe (Webhook) → Filter (amount > $50) → Supabase (Log Revenue) → Slack (Celebrate)

When Stripe processes a payment over $50, log it to your revenue table and send a celebration alert to Slack. The filter means small purchases flow silently while big wins get immediate visibility.

The Data Mapping System

The most important concept in Make.com is data mapping — how you reference output from one module inside another. This is what makes the conveyor belt work.

Make.com — Data mapping in the Email Capture scenario

// Module 1 — Webhook receives this JSON from your website:
{ "email": "user@example.com", "name": "Alex" }

// Module 2 — Resend uses {{1.email}} to pull from Module 1:
To:      {{1.email}}   → becomes: user@example.com
Subject: "Welcome, {{1.name}}!"  → becomes: "Welcome, Alex!"

// Module 3 — Supabase also pulls from Module 1:
email:     {{1.email}}
name:      {{1.name}}
joined_at: {{now}}     → built-in: current timestamp

// Module 4 — Slack can reference ANY previous module:
Message: "New sub: {{1.name}} ({{1.email}})"

Common mistake: The number in {{1.email}} is the module position, not an array index. Module 1 is always your trigger. If you insert a new module between #2 and #3, all downstream references shift — Make.com handles this automatically, but understanding it prevents confusion when debugging.

Advanced Modules: Router, Filter, Iterator

Basic scenarios are linear chains. Advanced scenarios use branching and looping to handle complex logic — still without writing code.

Module	What It Does	When to Use It
Router	Splits the flow into parallel paths. Each path gets its own filter condition.	Send different Slack messages for high-value vs. low-value payments. Route errors to a different channel than successes.
Filter	Stops the flow if a condition is not met. Data only passes through if the condition is true.	Only process payments over $50. Only send notifications during business hours. Skip duplicate emails.
Iterator	Takes an array and processes each item one at a time through downstream modules.	A webhook sends 10 line items — process each one separately. Loop through a list of emails to send individual messages.
Aggregator	Collects multiple items back into a single bundle after an Iterator.	After processing 10 line items individually, combine the results into one summary for Slack or a spreadsheet row.

Error Handling: Never Fail Silently

The most dangerous automation is one that fails without telling you. Make.com gives you two tools to prevent silent failures:

Error Handler Routes

Right-click any module and add an error handler. This creates a parallel path that fires only when that module fails. Route errors to Slack, email, or a logging table. Every production scenario should have error handlers on modules that call external APIs — because external services fail, and you need to know when they do.

✓

Incomplete Execution Queue

When a scenario fails mid-execution, Make.com stores the failed run in the Incomplete Executions queue. You can inspect the data, fix the issue, and re-run the exact same execution. This means no data is lost on failure — you always get a second chance.

Building Your First Scenario: Step by Step

The fastest way to learn Make.com is to build a simple three-module scenario. Here is the recommended starting point:

1. Create a new scenario and add a Custom Webhook module as the trigger

2. Make.com gives you a unique webhook URL — copy it

3. Add a Supabase → Insert Row module — map the webhook data to table columns

4. Add a Slack → Post Message module — compose a message using {{1.email}}

5. Click Run Once — then send a test POST to your webhook URL

6. Verify: check Supabase for the new row, check Slack for the notification

Terminal — Test your webhook with curl

# Send a test payload to your Make.com webhook
curl -X POST https://hook.make.com/your-webhook-id \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","name":"Alex"}'

# If successful, you should see:
# → A new row in your Supabase subscribers table
# → A Slack message saying "New sub: Alex (test@example.com)"

Pro tip: Always use Run Once to test before enabling scheduling. Check every module's output bubble (the green circle) to verify data flows correctly. Only turn on the scenario schedule once every module passes your manual test.

Operations and Pricing

Make.com charges by operations — each module execution counts as one operation. A 4-module scenario run = 4 operations. Understanding this prevents billing surprises.

Plan	Ops/Month	Best For
Free	1,000	Learning, testing, low-volume automations (a 4-module scenario can run 250 times/month)
Core ($9/mo)	10,000	Active indie projects — enough for hundreds of daily automations
Pro ($16/mo)	10,000+	Priority execution, custom functions, full-text log search