AI Chatbot Make Integration

Two different jobs Make can do for a chatbot

A chatbot connects to Make in one of two ways, and they have very different requirements. Getting clear on which one you need is the first design decision, because it shapes how every scenario is built.

After the conversation: an event pipeline

When something meaningful happens in a chat (a lead is captured, a booking is requested, a visitor asks for a human, a conversation closes), the chatbot’s backend posts a JSON payload to a Make custom webhook. A scenario picks it up and distributes it: a contact created or updated in the CRM, a row added to a sheet, a message in your team channel, a follow-up email queued. Nobody is waiting on the result. If a step takes twenty seconds, the visitor never notices.

During the conversation: a tool the bot calls

Sometimes the bot needs an answer before it can reply. Is this ZIP code inside the service area? Is an order shipped yet? Which of three packages fits the answers given so far? Here the scenario receives a request, looks something up and returns data to the bot with Make’s Webhook response module. A visitor is watching a typing indicator the whole time, so this path must be short, predictable and backed by a fallback.

Most projects start with the first role and add the second only for lookups that clearly improve the conversation. A few lookups are better written as direct code, which the comparison further down this page explains.

Inside a typical lead-capture scenario

Here is how we lay out a scenario that receives chatbot events. The order of the first few modules matters more than people expect.

The webhook’s data structure is defined from a real sample payload, so later modules map fields by name. We also add a schema version field to every payload the chatbot sends. When the chatbot changes, perhaps with a new qualifying question, the version bumps, and the scenario can route unfamiliar versions to a review branch instead of silently writing blank fields into your CRM.

Chatbot payloads often contain lists, such as several items in a quote request or multiple answers to one question. Make’s Iterator splits an array into separate bundles so each item can be processed, and an Array aggregator gathers them back together, for instance to send one email listing every item rather than five separate emails.

The synchronous path: when the bot waits on Make

A lookup scenario ends with a Webhook response module that returns a status code and a JSON body the bot can read. The rules we follow for this path:

• Keep it short. A handful of modules, one external call where possible, no long loops. Every module adds latency the visitor feels.
• Give it its own scenario. Event processing often uses Make’s sequential processing setting, so webhook requests are handled strictly in order. That is excellent for data integrity and poor for response time. Mixing both jobs in one scenario puts a live visitor in line behind a batch of CRM writes.
• Set the timeout on the chatbot side. The bot waits a fixed time that suits a conversation. If Make has not answered, the bot says it will confirm the detail by follow-up, never guessing in the meantime.
• Offer the model a fixed menu. The AI never composes arbitrary requests to Make. It chooses from a short list of defined tools with typed parameters, the backend validates those parameters, and the scenario validates them again with a filter.
• Return only what the bot needs. If the question is “is this address in the service area,” the response is yes or no plus the branch name, not the whole customer record.

A Make webhook URL works like a password

Anyone who knows a custom webhook’s URL can post data to it. Treating that URL casually is the most common security gap we find in existing Make setups. What we do instead:

1. Keep the URL server-side. The chatbot’s backend calls Make. The URL never appears in browser JavaScript, where any visitor can open developer tools and read it.
2. Check a shared secret first. The chatbot sends a secret header, the webhook is configured to pass request headers into the scenario, and a filter compares the value before any other module runs.
3. Restrict by network where possible. When the chatbot server has fixed outbound addresses, limiting the webhook to those addresses adds another layer. Whether that option is available on your account is checked during scoping.
4. Rotate when in doubt. If the URL may have leaked, a new webhook is created, the backend is updated, and the old one is removed.
5. Use a dedicated integration user. Make stores the credentials for each connected app as a connection. We authorize those connections with a least-privilege integration account in your CRM or email platform, not the owner’s personal login, so nothing breaks when an employee leaves and the scenario cannot reach more than it needs.

Data minimization belongs here too. Make keeps execution details in scenario history, which is invaluable for debugging. For sensitive payloads, Make’s scenario settings include an option to treat data as confidential so those details are not retained, at the cost of harder troubleshooting. We make that trade-off with you per scenario, and we avoid routing full transcripts through Make when a summary and a record ID will do.

When a module fails: error handlers and incomplete executions

Out of the box, an unhandled error ends the run, and depending on the scenario settings and trigger type, errors can switch a scenario off entirely. The chatbot keeps posting, the webhook queue fills, and nobody realizes leads have stopped reaching the CRM. Make provides the tools to prevent that, but they have to be wired in deliberately.

Error handler routes attach to individual modules and end in a directive: Resume continues with a substitute value, Ignore skips the failed bundle, Break stores the run as an incomplete execution that can be retried, and Commit or Rollback settle transactional steps. Our usual pattern:

• Temporary failures on external calls, such as a rate-limit response or a timeout from the CRM, go to Break with automatic retries enabled, so the run completes once the service recovers.
• Permanent failures, such as a rejected email address or a missing required field, never retry forever. They go to a needs-review branch that notifies a person with the event ID and the reason.
• Every error branch ends in a human-visible alert. A handled error that nobody hears about is only a quieter failure.
• Storing incomplete executions stays switched on, so a failed run can be fixed and resumed with its original data instead of being lost.

Two more safeguards sit outside Make. The chatbot writes each lead to its own storage before posting it, so Make is never the only copy. And bursts are throttled, through sequential processing or a deliberate pause between calls, so a busy evening does not trip the CRM’s rate limits all at once.

Keeping Make usage predictable

Make meters activity per module run, historically counted as operations. Make has been changing how it labels and prices that unit, so we check the terms of your current plan instead of assuming. Whatever the label, the mechanics are the same, and they reward careful design:

• Instant triggers beat polling. A polling trigger spends usage every time it checks, even when nothing is new. A webhook runs only when the chatbot actually has something to send.
• Filter early. A filter placed right after the trigger stops irrelevant events before they run six more modules.
• Watch the multipliers. An Iterator turns one bundle into many, and every module after it runs once per item.
• Send milestones, not messages. A chatbot that posts every individual chat message to Make multiplies usage by conversation length. Posting at milestones, such as lead captured or chat closed, keeps it proportional to outcomes.

During scoping we estimate module runs per conversation for each scenario and compare the total with the allowance on your plan, so there are no surprises when traffic grows.

Make, Zapier or custom code for your chatbot?

Our advice is usually practical rather than ideological. If your team already runs its operations in Make, we build there, because a second platform means a second place for things to break. If you are already on Zapier, our AI chatbot Zapier integration page covers that route. For lookups that must be fast, touch sensitive data or involve complex logic, a small piece of direct code through our chatbot API integration work is often the cleaner choice, with Make still handling the after-the-chat distribution.

How EVOTECH builds and hands over a Make integration

1. Free consultation by phone or video: which chatbot you use, which systems should receive its events and what already runs in Make.
2. Audit of your Make organization, including existing scenarios, connections, plan limits and anything that already touches the same CRM.
3. A fixed-scope written quote with a scenario map: triggers, branches, target systems, error routes and expected usage.
4. Build in your account. You invite us as a team member, and every scenario and connection stays yours. We do not build client automations in an account we control.
5. Testing with Run once and recorded sample payloads, covering a normal lead, a duplicate, a forged request without the secret, a malformed payload, an unfamiliar schema version and a simulated CRM outage.
6. Handover of exported scenario blueprints as a versioned backup, plus a short document explaining each scenario’s purpose, trigger, connections, error routes and who gets alerted.

EVOTECH IT LLC is an independent developer building on Make’s public platform; we are not a Make partner. Our record: two-plus decades in business and a 5.0 score on Google, from a Houston-area team that works remotely with clients nationwide. Ring us at (832) 359-2425 and bring a list of the scenarios you already run.

Related services

Frequently asked questions