What Make Actually Is

Make is a visual automation platform that lets you chain together services, APIs, and logic blocks into scenarios that run on a schedule or in response to triggers. It used to be called Integromat and rebranded to Make in 2022, so if you have heard the older name, that is the same product.

Under the hood, a scenario is a directed graph of modules. Each module is a node that performs one action: fetch a record, send an email, call an API, transform data, branch on a condition. Modules are wired together, data flows from one to the next as bundles, and the whole thing executes in order with optional parallel branches and routers.

The pricing model is operations-based. Every module that runs counts as one operation, so a scenario with five modules that fires 100 times costs 500 operations. This is the single most important thing to understand about Make because it directly shapes what you build and how you build it. Heavy scenarios get expensive quickly, and the cost ceiling is what stops people from scaling naive designs.

Make ships with hundreds of pre-built app modules covering the usual suspects: Google Workspace, Slack, Notion, Airtable, HubSpot, Salesforce, OpenAI, Anthropic, and most CRMs and marketing tools. When a module does not exist for what you need, the HTTP module lets you call any REST API directly, which means Make can integrate with anything that has an API.

For AI workflows specifically, Make is useful because it handles the orchestration layer that most LLM APIs do not provide on their own. You can build a scenario that watches a webhook, sends the payload to an LLM, parses the response, writes the result to a database, and notifies a human reviewer on Slack. That kind of multi-step pipeline is exactly what Make is designed for.

Setup and Authentication

Start at make.com and create a free account. The free tier gives you 1,000 operations per month and access to most apps, which is enough to build and test real scenarios before committing to a paid plan.

Once you are in, the workspace is divided into three areas you will use constantly: Scenarios (where your automations live), Apps (where you configure connections to external services), and Teams (where you manage users and permissions on paid plans).

Authentication for most apps works through connections. Click Apps, choose the service, and Make walks you through either OAuth (where you log in to the service and grant access) or an API key (where you paste a token from the service’s developer console). For services like OpenAI, Anthropic, and most AI providers, you will use API keys. For Google, Slack, Notion, and similar, OAuth is the default and the cleanest path.

A few practical tips on auth:

Store API keys in Make’s connection system rather than hardcoding them in HTTP modules. The connection system encrypts credentials and lets you rotate keys without rebuilding scenarios.

Use separate connections for development and production. Make lets you create multiple connections to the same service, so build a “dev” connection pointing at a sandbox and a “prod” connection pointing at live data.

For team plans, set up role-based access so only specific users can edit production scenarios. Make supports viewer, editor, and admin roles per scenario, which matters once you have more than one person touching the system.

If you are running Make against your own infrastructure, you can also self-host the open-source Make SDK or use the on-prem version of the platform, though most users will stick with the cloud product.

First Working Example

Let me build a concrete scenario you can run in the next 15 minutes. The goal: receive a webhook, send the payload to an AI model for summarization, and post the summary to a Slack channel.

Step 1. Create a new scenario from the dashboard. Name it “Webhook to Slack Summary.”

Step 2. Add the first module. Search for “Webhooks” and choose the Custom webhook trigger. Make will generate a unique URL for you. Copy it. This is the endpoint your external system will POST to.

Step 3. Add an OpenAI module. Search for “OpenAI” and pick “Create a Completion” (or “Create a Chat Completion” depending on the current module set). Choose your OpenAI connection, paste your API key the first time, and set the model. In the prompt field, use the webhook payload as input. The exact mapping looks like {{1.body.text}} where 1 refers to the first module and body.text is the JSON path of your incoming payload.

Step 4. Add a Slack module. Search for “Slack” and pick “Create a Message.” Choose your Slack connection, pick the channel, and in the message text field, reference the OpenAI output with {{2.result}} or whatever the current output mapping is. Make shows you the available variables in a panel on the right side of the module, so you do not have to guess.

Step 5. Save the scenario, toggle it on, and POST a test payload to your webhook URL using curl or any HTTP client. Within seconds the summary should appear in Slack.

That is a working AI workflow. The same pattern, webhook in, AI call, downstream action, scales to almost any use case: customer support ticket triage, lead scoring, content moderation, document classification, internal Q&A bots.

The key thing to notice is how Make handles data passing between modules. Each module produces a bundle of fields, and you reference those fields in subsequent modules using the {{moduleNumber.field}} syntax. Click any field in a module and Make shows you the mapping helper. This is the single most important UI feature to learn because you will use it constantly.

Key Settings That Matter

Most people ignore the settings that actually determine whether a scenario is reliable or expensive. Here are the ones that matter.

Scheduling. Every scenario has a schedule setting that controls how often it runs. The default is every 15 minutes, but you can set it to run on demand only (when triggered by a webhook), every minute, or on a custom cron expression. For high-volume scenarios, switch to on-demand triggers to avoid burning operations on empty polls.

Error handling. This is the setting that separates production-grade scenarios from toys. Open any module and you will see an “Error handling” section with options for Resume, Rollback, Commit, and Stop. The default is to stop the scenario on error, which is fine for development but risky in production. For most modules, set it to Resume with a fallback route so the scenario continues even if one record fails. Pair this with an error router at the scenario level to catch failures and send them to a notification module.

Filters. Filters let you skip a module based on a condition. If you only want to process records where a field is non-empty, add a filter between modules. Filters do not consume operations when they reject, so they are a cheap way to cut down on wasted work.

Iterators and aggregators. An iterator splits a bundle array into individual bundles, one per item. An aggregator combines multiple bundles back into one. These two modules together let you handle batch operations, like processing 50 rows from a spreadsheet in a single scenario run. The pattern is: fetch all rows, iterate, do work per row, aggregate results, write back.

Data stores. Make has a built-in key-value store called Data Store. Use it for state that needs to persist between scenario runs, like tracking which records have been processed, storing API rate limit counters, or caching lookup data. Data Store is cheaper than hitting an external database for small state.

Bundle limits. Each module has a “Max number of bundles” setting that defaults to 1. If you want a module to process multiple incoming bundles in one run, bump this up. This is how you process a batch of records without running the scenario 100 times.

Parallelism. Make supports parallel execution across branches. If your scenario has two independent steps, put them on separate branches and they run simultaneously. This cuts total execution time roughly in half for I/O-bound workflows.

Where It Shines

Make genuinely excels at multi-step integrations that mix multiple services with conditional logic. If your workflow has more than three steps and involves branching, Make is usually faster to build than writing the same thing in code.

AI orchestration is the current sweet spot. The platform has first-class modules for OpenAI, Anthropic, and other LLM providers, and the visual structure makes it easy to build pipelines like “fetch customer message, classify intent, route to the right team, draft a response, send for human approval.” That kind of workflow is painful to build from scratch with raw API calls, and Make handles the plumbing.

Internal tools and ops automation is another strong fit. Marketing teams use Make to sync data between CRMs and email platforms. Finance teams use it to reconcile transactions. Ops teams use it to monitor inboxes and route urgent items. The visual builder means non-engineers can modify workflows without deploying code.

Webhook-driven workflows are particularly clean because Make handles the webhook infrastructure for you. You do not need to run a server, expose a port, or manage certificates. Make gives you a URL, you POST to it, and the scenario runs.

The HTTP module also makes Make a reasonable choice as a lightweight API gateway. You can build a scenario that receives a webhook, validates the payload, calls three different downstream APIs in parallel, aggregates the responses, and returns a custom JSON body. That is a real microservice built without writing server code.

Where It Fails

Make has real limitations and you should know them before committing to it for production use.

Cost scaling is the biggest one. Operations-based pricing means heavy scenarios get expensive fast. A scenario that processes 10,000 records per day with five modules per record is 50,000 operations daily, which lands you on the higher-tier plans quickly. If your workflow is genuinely high-volume, a self-hosted solution or a code-based approach is usually cheaper.

Complex branching logic is awkward. Make supports routers and filters, but deeply nested conditional logic becomes hard to read and maintain. If your workflow has more than four or five branches, you are probably better off writing code.

Version control is weak. Scenarios live in Make’s database, not in git. There is no native way to diff two versions of a scenario, review changes, or roll back to a previous version. Make has a version history feature but it is not a substitute for proper version control. For teams that need code review on automation changes, this is a real friction point.

Real-time performance is limited. The minimum scheduling interval is one minute, and webhook-triggered scenarios have a small startup latency. If you need sub-second response times, Make is not the right tool.

Error recovery is basic. When something fails, Make can resume, rollback, or stop, but there is no built-in retry with exponential backoff for transient failures. You have to build that yourself with routers and counters.

Testing is manual. There is no proper unit testing framework for scenarios. You can run a scenario once with sample data, but there is no way to assert “this module produced the expected output” the way you would in a code test suite. For mission-critical workflows, this means you need to test in a staging environment and monitor carefully in production.

Practical Workflow Pattern

Here is how I would slot Make into a real work setup if I were starting today.

Treat scenarios like code. Use a naming convention that includes the owner, the purpose, and the environment: acme-prod-customer-triage is better than Scenario 47. Document each scenario with a description field that explains what it does, who owns it, and what it depends on.

Build a staging environment. Most apps support sandbox or test mode. Use Make’s folder structure to separate dev scenarios from prod scenarios. Never test against production data.

Monitor operations usage. Make shows you operation counts per scenario in the dashboard. Set up a Slack notification that fires when daily operations exceed a threshold so you catch runaway scenarios before they cost you money.

Use Data Store for state, not for source-of-truth data. Make’s Data Store is fine for tracking which records have been processed, but do not use it as your primary database. Keep your real data in a proper system and use Make to move and transform it.

Version your scenarios by exporting them. Make lets you export a scenario as a JSON blueprint. Store these in a git repo with a README explaining the deployment process. This is not a perfect substitute for version control, but it gives you a record of changes and a way to redeploy.

Build small, composable scenarios rather than one giant scenario. A scenario with 30 modules is hard to debug. Break it into smaller scenarios that hand off via webhooks or Data Store. This also makes it easier to reuse parts of the workflow.

For AI workflows specifically, design for human review. AI outputs are probabilistic, and you want a human in the loop for anything that touches customers or makes business decisions. Use Make to draft, route for approval, and only act after a human signs off.

Finally, know when to graduate out of Make. If a scenario becomes critical, high-volume, or deeply complex, the right move is to rewrite it as a proper application with version control, testing, and observability. Make is a great place to prototype and to run workflows that do not justify a full engineering investment, but it is not the final destination for everything.

To see how tools like this fit into a complete AI operating layer for your business, book a 60-min Omni Audit — https://calendly.com/sam-mckay/discovery-call