The Core Tools: What You Actually Need
When you open Make.com for the first time, the module library is overwhelming. There are hundreds of apps and tools. But honestly? You'll only use about 15% of them for 95% of your work.
I've been running seven live tools on Make.com for the past three years. Shadow Hound (AI resume optimizer), Social Spark (content generator), KPI Dashboard, Tailored Social Post, Blog Post Generator, Kid-Friendly Story Book, and Voice ToDo. Every single one is built on the same core toolkit. No fancy modules. No premium integrations. Just webhooks, HTTP requests, and conditional logic.
Let me walk you through exactly what's in my toolbelt and why each piece matters.
Webhooks: The Entry Point to Everything
Every single one of my tools starts with a webhook. This is the bridge between the outside world and Make.com.
Here's how it works: You create a custom webhook in Make.com (it's just a unique URL). Then you send data to that URL from your frontend, an email, another app, wherever. Make.com receives it and triggers your scenario.
For Shadow Hound, when someone pastes their resume and hits "Optimize," JavaScript on my frontend makes a POST request to my Make.com webhook. The webhook receives the resume text, and boom — the entire automation kicks off. I get the parsed resume, send it to OpenAI, generate feedback, and email it back to the user.
What makes webhooks powerful is that they're completely flexible. You can send any data structure you want. JSON, form-encoded, whatever. Make.com will parse it and let you access each field in your scenario.
Pro tip: Always test your webhook with actual data before connecting it to your frontend. Use Postman or curl to send test requests. It saves so much debugging time.
The HTTP Module: Your Universal API Client
After the webhook receives data, the next step is usually an HTTP request. This is Make.com's most underrated tool.
The HTTP module lets you make GET, POST, PUT, DELETE requests to literally any API. OpenAI, Airtable, Google Sheets, your own backend, anything. You're not locked into Make.com's pre-built integrations.
For Social Spark, I use the HTTP module to hit OpenAI's API directly. Why? Because Make.com's built-in OpenAI module is limiting. I need fine control over the system prompt, temperature, token limits, and response formatting. The HTTP module gives me that control.
Here's a typical HTTP request in Social Spark:
- URL: https://api.openai.com/v1/chat/completions
- Method: POST
- Headers: Content-Type: application/json, Authorization: Bearer [API_KEY]
- Body: JSON with model, messages, temperature, max_tokens, response_format
The HTTP module parses the response (usually JSON) and makes every field accessible. Then I can filter, transform, and pass that data downstream.
This flexibility is why I've never hit a wall with Make.com. If an integration isn't available, I just use HTTP and connect it myself.
The OpenAI Module (and When to Use It vs. HTTP)
Make.com has a native OpenAI module. It's convenient. It's also limited if you know what you're doing.
I use it when I need something simple and don't care about granular control. For my Kid-Friendly Story Book tool, the logic is straightforward: receive a prompt, send it to GPT-4, get back a story. The native module works fine.
But for anything where I need to customize the system prompt, temperature, or response format? I switch to HTTP and call the API directly. It's not much more complex, and the control is worth it.
The key is knowing the difference. Use the native module for speed and simplicity. Use HTTP for power and customization.
One thing I've learned: system prompts matter way more than people think. A well-crafted system prompt can make the difference between a useless output and something amazing. I spend time iterating on them, testing different phrasings, measuring quality. That's where the real work is.
Airtable: Your Persistent Data Layer
Most of my tools need to store data. User info, previous results, configuration, logs. I use Airtable for all of it.
The Make.com Airtable module is solid. You can create records, update them, search, delete. It's straightforward.
For the KPI Dashboard, every time someone logs in, I write their metrics to Airtable. Every time a user generates content with Social Spark, I log it. This gives me historical data that I can query later.
I could use HTTP to hit Airtable's API directly (and sometimes I do for complex queries), but the native module is actually good enough for most cases.
Here's the architecture: webhook receives data → I optionally fetch user info from Airtable → process the data → send to OpenAI → write results back to Airtable → deliver to user.
The Airtable integration is the central nervous system. Everything flows through it.
Routers and Filters: Conditional Logic
Not every webhook request is the same. Sometimes you need different behavior based on what data was sent.
That's where routers and filters come in.
A filter is simple: "If X condition is true, continue. Otherwise, stop." For example, in Shadow Hound, after I parse the resume and generate feedback, I check: "Is an email address provided?" If yes, continue to the email step. If no, stop and return an error.
A router is more powerful. It's like a switch statement. Based on a value, route to different parts of your scenario. For example, in Social Spark, the user can choose from three content types: LinkedIn post, Twitter thread, or blog outline. The router checks that value and sends the request to the appropriate processing branch.
These tools keep your scenarios clean. Without them, everything would be nested if-then logic that's hard to follow.
I usually keep routers at a high level and filters spread throughout. Routers split the main flow. Filters handle edge cases and validation.
The Tools I Almost Never Use
There are modules that look useful but end up being friction. I try to be honest about this.
Scheduled triggers: Make.com's scheduling module is clunky. I almost always prefer HTTP webhooks triggered by cron jobs or Google Sheets scheduled scripts. More flexible, easier to debug.
Iterator: This module is supposed to let you loop through arrays. It works, but I almost always find a cleaner way to structure my data so I don't need it. Usually means rethinking the upstream logic.
Aggregator: Similar issue. Rarely needed if you design your data flow properly from the start.
Text parsing (regex): Make.com's built-in text parsing is weak. If I need serious string manipulation, I usually make an HTTP call to a small OpenAI endpoint (super cheap) or restructure my data format. Sounds excessive, but it's cleaner than trying to build complex regex in Make.com.
Pre-built app modules: This is controversial, but I avoid most of the pre-built integrations (Slack, Google Drive, etc.). The HTTP module works with their APIs just fine, gives me more control, and I don't have to learn a new UI for every app. Once you're comfortable with HTTP, pre-built modules feel limiting.
The modules I use are boring: webhooks, HTTP, native Airtable and OpenAI, routers, filters. That's it. And they're enough to build anything.
Why This Matters
The more I've used Make.com, the more I've realized that the platform's strength isn't its breadth of integrations. It's the core tools. Webhooks, HTTP, conditional logic, and a persistent data layer (Airtable).
Understanding these well means you're not dependent on whether Make.com has a specific integration for whatever service you want to use. You can connect anything. You have agency.
New users often get stuck trying to find the "right" module for their use case. Stop looking. Pick the boring core tools and learn them inside and out. You'll move faster and build more resilient automations.