What is a Make.com integration, really?
By an integration we mean: data moves automatically from one system to another, without anyone retyping it. A new customer in your CRM appears in your accounting by itself, a submitted form becomes a task, a paid order becomes an invoice.
In Make you build such an integration as a scenario: a chain of modules that starts with a trigger. The difference with a "real" custom integration is that you do not write and host code yourself. Make takes care of running it, logging in to the systems and keeping logs. You decide what happens.
That makes Make a good fit for most SME integrations: a few systems, hundreds to thousands of records a day, and processes you can describe clearly. For an overview of scenarios that come up often, see Make.com workflows for SMEs. This article is about the step before that: how you connect to a system in the first place.
Which route do you choose: app, HTTP module or webhook?
For each system you want to connect, you choose one of three routes. Often you mix several in a single scenario.
1. A ready-made app in Make
For many well-known packages Make has its own app with modules such as "search a contact", "create an invoice" or "watch new orders". You log in once, and from then on you pick fields from a list. This is the fastest and easiest route to maintain. Do check which modules are available: an app does not always offer everything the package itself can do.
2. The HTTP module and the package's API
If a package has no app in Make, or the app lacks the function you need, you talk directly to the package's API. You do that with the Make a request module from the HTTP app. According to Make's documentation (checked on 23 October 2026), that module supports the common methods (GET, POST, PUT, PATCH, DELETE), can page through results by itself, and lets you authenticate with an API key, username and password, or OAuth 2.0. Keys are stored in Make's keychain rather than as plain text in the module.
This route takes more knowledge: you need to be able to read the package's API documentation and understand what the response looks like. In return, you can use everything the API offers.
3. A webhook
A webhook reverses the direction. Instead of Make asking over and over "is there anything new?", the other system sends a signal to an address in Make as soon as something happens. You create that address with the Custom webhook module. The scenario then starts immediately, and only when there is actually something to do. That saves credits and waiting time.
A webhook only works if the source system can send webhooks. Web forms and webshops often can; some accounting and CRM packages cannot, or only for certain events.
How do you choose the right route per system?
A simple order that works well in practice:
- Is there an app in Make with the modules you need? Use it.
- Can the source system send a webhook for the event you want to follow? Use that as the trigger, even if you continue with app modules afterwards.
- Neither? Use the HTTP module with the package's API, possibly as a scheduled trigger that checks at a fixed interval what is new.
If a package has no API at all, Make often reaches its limit. Sometimes an export to a shared folder or a mailbox is the only way out, which Make can then pick up. That works, but it is more fragile. Our integrations page shows which packages we often connect.
How do you make sure the right data ends up together?
Most problems with integrations are not in the technology, but in the translation between two systems. Agree on three things upfront:
- A fixed key. How do you recognise that a customer in system A is the same one as in system B? An email address, a Chamber of Commerce number or a customer number stored in both systems. Without a fixed key, an integration will sooner or later create duplicates.
- One source per data point. Decide per field which system leads. If both systems update each other, you end up with a ping-pong of changes.
- A field list. A simple table: field in system A, field in system B, and what changes along the way. Think of date formats, VAT codes, country codes and picklists that are named differently in each package.
That field list is also your documentation. When someone else needs to change the integration a year from now, it is the first thing they will need.
Step by step: a Make.com integration in six steps
A fictional example to make it concrete. An installation company with twenty employees receives requests through a form on its website. A colleague retypes them into the CRM and turns them into a task for the planner. They want to connect the two.
- Describe the event and the outcome. Event: a submitted form. Outcome: a contact in the CRM (new or existing) with a task for the planner.
- Choose the route per system. The form can send a webhook, so that becomes the trigger. The CRM has an app in Make with modules to search, create and add a task.
- Set up access. Create a connection to the CRM in Make, preferably with a dedicated user or API key for integrations, not a colleague's personal account. If that colleague leaves, the integration keeps working.
- Build the fields and the key. First search by email address whether the contact already exists. If so, link the task to that contact. If not, create it. Put the fields from your field list in place.
- Test with real examples. A new customer, an existing customer, a form with a typo in the email address, a form without a phone number. Check for each test what ends up in the CRM.
- Set up error handling and an owner. If a step fails, the colleague who does the work today receives an email with the form data. And there is one name attached to the integration: who looks at it when something goes wrong?
If you use Cirqll as your CRM, a similar scenario is worked out in Cirqll and Make.com: 5 automations.
Where does a Make.com integration usually go wrong?
A few pitfalls we see often, along with what Make itself says in its documentation (checked on 23 October 2026):
- The connection expires or loses permissions. A password is changed, a user is disabled or an API key is revoked. The integration then fails on the first run. Use a dedicated integration user and note where the key comes from.
- A scenario stops after errors. According to Make, a scenario with an instant trigger stops at the first error, a scheduled scenario after three errors in a row. Without an alert, nobody notices. How to catch that is covered in Make.com error handling.
- A webhook without a scenario. Make deactivates a webhook that has not been attached to any scenario for more than five days. If you rebuild an integration, check that the webhook address is still active.
- Too much at once. According to the documentation, a webhook in Make handles up to 300 requests per ten seconds; requests above that are rejected. For most SME processes that is plenty, but a large one-off import can hit it.
- Silent changes on the other side. A vendor changes its API or renames a picklist. Test your integrations after major updates to a package, and keep the field list up to date.
When is a Make integration not enough?
Make is strong at moving individual records at the moment something happens. It is less suited to collecting large amounts of data for reporting, or to situations where the same data is fetched and transformed again in five scenarios. Then you are quietly building a second administration inside Make.
In that case a central data foundation is often smarter: one place where your data is clean and connected, ready for your dashboards and your workflows. Make stays perfectly fine for the actions, such as creating a task or sending an alert. Not sure whether Make is the right platform at all? Also read Make vs n8n.
Need help with your Make.com integration?
Want to connect two systems but not sure which route fits, or already running an integration that keeps stalling? We are happy to look at your systems and processes, and we build Make integrations with a field list, error handling and a fixed owner. See what we do in workflow automation or read how we work.