Two integration platforms. Both promise depth, autonomy and AI. This page compares what each one actually requires of your team, across forty-nine jobs.
Each line opens the row it came from, with the scenario and the documentation behind it. Read them sceptically: that is what the rest of this page is for.
Why the promises tell you nothing, in one analogy:
Two cars, both advertised as self-driving. One parks itself in your driveway. The other drives Philadelphia to Denver while you sleep. Same words on the brochure. Not the same product.
Same two words on both brochures. Two completely different products.
Integration platforms are harder: there is no test drive. Every vendor writes the same words: deep, autonomous, AI-powered, enterprise-grade. Words are free. You find out what you bought in month nine, when a customer reports a failed sync and you need to know exactly what happened. Or in year two, when the engineer who built it is gone.
So this is not a page of claims. It is a page of jobs. A real thing that has to happen. What happens on APIANT, step by step. What the same job requires on Make, in its own documentation's words.
Apply the same scepticism to us. Read the architecture, not the adjectives. And take three questions with you into every vendor conversation you have after this one:
After the AI has done the work, is there a representation a non-developer can open, read, and judge? Building something and being able to look at it afterwards are two different capabilities.
Jump to Capability 01, where it bites hardest → TEST 02Never accept a depth claim. Test it against the specific API you need: the private endpoint no catalog lists, the forty custom fields, the rate limit, the pagination quirk.
Jump to Capability 06, the uncatalogued endpoint → TEST 03Every AI gets something wrong eventually. The question is what, in the architecture, is positioned to catch a wrong result before your customer sees it.
Jump to Capability 21, the answer to it →These three tests run on every one of the forty-nine capabilities on this page. By the third section you will be asking them yourself.
Integration work is where your roadmap goes to wait. Deals stall on a connector that does not exist yet, engineers get pulled off product to fix a sync, and a single "it didn't work for one customer last Tuesday" can absorb a week of senior time. Whichever platform you choose, you will live inside its architecture for years. This page shows you what each one actually requires of your team, job by job.
A note on method. Every vendor in this category claims depth, autonomy, and reliability, and you have no way to adjudicate competing claims. So this page does something else: it takes concrete jobs and shows what each platform's architecture requires to get them done. APIANT's side is a walkthrough of shipping capabilities. Make's side is derived from Make's own documentation, repositories, and pricing page, quoted where a quote beats a paraphrase. Where their design handles a job well, we say so.
How to read this page. Every row is one capability. Bright text is what you get on APIANT; muted text after the dot is what the same job costs on Make. Skim the forty-nine takeaways and open any row that matters. Inside each: the problem that forced the capability to exist, a concrete scenario, how it goes on APIANT, and what the same outcome requires on Make. Skim the bold lines first. The argument is the pile, not any single row.
Reuse and in-place editing are real on Make and we concede them: with subscenarios, "Update the logic once, and all parent scenarios benefit automatically." The published bounds are where it costs: "You can only call a scenario created in your team", every machine write sends "the blueprint ... as a string, not as an object", and "only the versions that are not older than 60 days can be retrieved." A paid run also carries a 40-minute clock, on AWS EU or North America on every plan.
Everything on this page traces back to one design decision made years before AI could build integrations: what is an integration made of? On APIANT the answer is structured data, all the way down. That choice looked like an implementation detail for a decade. It is now the whole ballgame.
A new hire asks the AI to rework invoice mapping, or does it herself in twenty minutes. Either way, no engineer. Elsewhere, machine edits swap the whole blueprint; versions expire at 60 days
Open the scenarioCode cannot be safely edited by a machine, inspected by a non-developer, or replayed with its state intact.
And that holds at every layer: the flow, the connectors inside it, each API operation, every mapping, every setting. All of it is structured data. That one choice is why a machine can edit it safely, a person can always inspect it, and a saved run can be replayed with its state intact.
Meridian, a field-services SaaS with 4,100 customers. In March, an AI built their QuickBooks invoice sync in a working session. In September, the engineer who supervised that session has left, and Dana, the new integrations lead (sharp, technical, not a developer), needs to change how invoice line items map for a segment of customers. The question that decides Dana's week: what did the AI actually hand Meridian in March?
Elapsed: about twenty minutes. No engineer involved. The March artifact and the September artifact are the same living thing.
The cost sits just past the reading: a person can open a Make scenario, but any machine edit replaces the entire artifact, and its history expires in two months.
Concede the artifact itself, because it is structured data, not code. "A blueprint is a reusable version of a scenario that includes: Scenario modules, Module settings, Mapped values," exportable as JSON text "which can be pasted into other scenarios in Make, LLMs, or other compatible tools" (help.make.com/blueprints). On the API, though, that structure travels as one opaque unit: "The scenario blueprint. To save resources, the blueprint is sent as a string, not as an object" (Make scenarios API reference), and no module-level or mapping-level write endpoint is published. Make's own published AI skill instructs the edit loop that follows, for every fix: "Call scenarios_deactivate on the scenario. Call scenarios_update with the corrected blueprint. Call scenarios_activate to re-enable" (integromat/make-skills, read 2026-08-26). Follow Make's own published loop and the live integration is offline while the whole blueprint is swapped; their API reference for PATCH /scenarios/{scenarioId} states no requirement to deactivate first, so the offline window is their instruction rather than a documented platform constraint. The write unit needs no such hedge: whole blueprint, on both the API and the CLI.
Rollback and portability carry published walls. "Version history lets you access and restore previously saved scenario versions for up to 60 days," and the API adds "Due to the regular archiving process, only the versions that are not older than 60 days can be retrieved" (developers.make.com, scenarios/blueprints). No version compare or diff view is documented. And the portable file has its own limits: "The imported blueprint must be below 2 MB in size," and "users still need to create connections for their accounts after importing the blueprint" (help.make.com/blueprints).
Both let an AI build the integration. The difference is what the AI hands you afterwards.
Quarter-end's 80MB file clears by 4am on the same path as a normal night. Elsewhere, a 40 minute run clock and per-plan file caps
Open the scenarioIntegrations died on large payloads, and on formats the platform had not anticipated.
Every record, file, and API response flows through a single engine with a small memory footprint. The platform does not care what shape your data arrives in or how much of it there is.
Caldera Health, a 38-clinic group. Every night at 1am, their practice-management system exports the day's claims and inventory as one file. On a normal Tuesday it is 12MB. At end of quarter it is 80MB. The integration has to parse it, reconcile it against the billing platform, and post corrections before clinics open at 7am. Nobody is awake to babysit it, which is the point.
Corrections post by 4am. Quarter end is not an incident category.
The cost is a clock and a set of caps you inherit: every job must fit a 40 minute run window and a per-plan file ceiling, or be redesigned into pieces.
On formats, concede parity: built-in JSON, XML, CSV, SOAP and MIME tooling exists, and the HTTP module posts JSON, multipart, form-encoded or custom content types (apps.make.com/http). The gap is size and duration, in their own published numbers. The pricing matrix carries the row "Maximum scenario execution time (minutes) Maximum run time of a single scenario execution." reading 5 | 40 | 40 | 40 | 40 across the Free, Core, Pro, Teams and Enterprise columns (https://www.make.com/en/pricing, seen 2026-08-26), so forty minutes is the ceiling on every paid plan, Enterprise included. Their troubleshooting documentation adds that "most Make modules have a runtime limit of 40 or 60 seconds", inside the ModuleTimeoutError explanation (https://help.make.com/fix-errors-and-warnings, seen 2026-08-26).
File ceilings are per plan: the row "Maximum file size (MB) Maximum size of file that you can automate and process." reads 5 | 100 | 250 | 500 | 1000 across the same five columns (https://www.make.com/en/pricing, seen 2026-08-26). The HTTP module's own pagination field concedes a per-request ceiling, with a manual workaround: "you can also use this field to return items beyond Make's 3200 limit" (https://apps.make.com/http, seen 2026-08-26). A large backfill, a big file, or a long sync gets decomposed to fit the clock; the platform does not stretch to the payload.
Your syncs queue behind your own traffic, at your own domain, on a dedicated server pair from the entry paid plan. Elsewhere, shared two-region cloud on every plan; own instance is an OEM engagement
Open the scenarioShared infrastructure means shared rate limits, shared incidents, and commingled customer data.
A 41-branch credit union circles one line in its security review: confirm member data is not commingled with other tenants, and name the domain traffic terminates on. The board votes in nine days.
Your integrations run on servers that are yours, addressed at your domain, with nobody else's traffic in the queue. You can even shut them down.
The cost is shared ground: your development, your production, and every other tenant run in the same two-region cloud, on every published plan. The pricing matrix states it in each plan column, Free through Enterprise: "Hosting: The location where we host the infrastructure that Make runs on: AWS (EU/North America)" (make.com/en/pricing). The region is picked once, at creation: "you cannot change the location of the data center after you create the organization" (help.make.com/organizations). Private networks are reached through an agent rather than a server of yours: "On-prem agent: Securely access local networks and use core business apps like SAP in your automations", an Enterprise pricing-table item whose installers require Java 11+. A separate instance exists, but as an OEM engagement rather than a plan. The White Label documentation opens with "Once your White Label instance has been implemented by Make", custom domains are configured "with Make's assistance" through a CSM process, and "A Base domain exists for all instances ... Always has our branding" at {{customName}}.onmake.com or {{customName}}.make.celonis.com (developers.make.com/white-label-documentation). No published plan lists customer-run dev and production servers.
Structurally invalid work is refused at build time, instead of surfacing later in production logs. Elsewhere, schema checks gate the build; correctness checking stays manual
Open the scenarioA generated integration that is syntactically fine and semantically wrong reaches production, and nobody knows until customer data is wrong.
After a hail week, 6,200 claims queue up. The integration pushing approved amounts into payments compiled and deployed cleanly. Farmers on the phone tell the claims supervisor which field it wrote.
The AI's intent passes through a constrained schema, and the compiler rejects invalid structures at the door. Ask for something malformed and watch the platform say no.
The cost is that valid and right are different tests, and the second test has no documented gate. Concede what is checked, because blueprint validation is real. The scenarios API can filter for "only invalid scenarios (those whose blueprint failed validation)" (Make scenarios API reference), and their AI build path validates configuration as it assembles: "Every module is validated individually via the MCP API before blueprint assembly. Catch configuration errors early, not after deployment" (skills.make.com). These are schema and configuration checks. Their own skills repo draws the boundary on the other test, in the step that reads a successful run: "status: 1 alone is not proof the scenario produced correct data. A module can complete without throwing and still hand downstream steps an empty or wrong value ... Make's execution status reflects 'did anything crash,' not 'is this output right.'" (github.com/integromat/make-skills, skills/make-scenario-building/SKILL.md, read 2026-08-26). On refusing to activate a scenario that validates but does the wrong thing, Make does not document this. We searched the scenarios API reference on developers.make.com, the scenario settings pages on help.make.com, and skills.make.com. On that basis, catching the semantically wrong build before it ships is manual test work rather than a platform behaviour.
Ask the AI which integrations use a broken lookup, fix it once, and every one of them inherits the fix, including the ones your team forgot about. Elsewhere, propagating reuse stops at the team wall; beyond it, copies
Open the scenarioThe same connector logic was being rebuilt per customer, and the copies diverged.
The shift lookup was built once, then copied into 60 trust integrations, and a February timezone correction reached 41 copies. On an audit call, a liaison asks which version each trust runs today.
Build an operation once ("get client services by product"), reuse it in every integration that needs it. Fix it once, every user of it inherits the fix.
The cost starts at the team boundary: reuse propagates inside one team, and becomes copy-and-diverge the moment a second team, or a second customer, is involved. Concede the inside story plainly. Subscenarios are a genuine propagating reuse unit: "Use the same subscenario across different parent scenarios instead of recreating modules ... Update the logic once, and all parent scenarios benefit automatically" (help.make.com/subscenarios). Custom apps reuse connector logic org-wide, and an app edit reaches every scenario using it at once: "All changes take effect immediately in running scenarios with private and public custom apps. You should take this into account while changing your code." (https://developers.make.com/custom-apps-documentation/app-maintenance/updating-your-app, seen 2026-08-26). The wall is published on the same pages. "You can only call a scenario created in your team" (help.make.com/subscenarios), and the teams documentation states that scenarios, connections, webhooks, data stores and custom functions "always belong to only one team. You can't change which team a particular item belongs to" (help.make.com/teams); below the Teams plan an organization has one team. Past the wall, reuse is a copy: a blueprint import ("The imported blueprint must be below 2 MB in size", "users still need to create connections for their accounts after importing the blueprint") or an API clone with per-clone mapping of "connections, data stores, webhooks, ..." from the original. Each customer copy then ages on its own.
The asset your company accumulates is a library of inspectable building blocks that any successor can open, not a portfolio of codebases that each had exactly one fluent reader, who has since changed jobs.
Reaching an API that is not in the catalog is hand-declared work: "There are six basic types of modules", declared one endpoint at a time in JSON and IML, and Make's own rule that "Every app using API should have a universal module" concedes the authored modules will not cover the whole API. Live schema discovery is genuine and worth conceding, but RPCs exist only where the app author built them, under a 40-second cap, and the raw-call fallback hands the builder the endpoint path, with the output shape arriving after the module has been run once.
Connector catalogs are where integration platforms compete in public, and it is the wrong contest. The integration a deal depends on is reliably the one no catalog lists. The real questions are time-to-new-connector, and how deep the connector goes once it exists.
A niche partner API becomes a working connector in one session, and the renewal survives. Elsewhere it arrives as a Node project, times forty clients. Elsewhere, a developer hand-declares each module in JSON and IML, and their own rule concedes the modules will not cover the whole API
Open the scenarioThe integration the deal depended on was never in anyone's catalog, and the catalog vendor had no incentive to add it.
Northgate, a systems integrator with forty managed clients. Their largest client runs bookings on a regional platform nobody has heard of outside its niche. The endpoints that matter, membership holds and multi-site transfers, live in the partner API, behind an NDA, in no catalog anywhere. The client's renewal is conditioned on this integration existing within the month.
The connector exists in a working session. The renewal conversation changes subject.
When the API your deal depends on is not in the catalog, Make's route is a Custom App a developer declares by hand, one module at a time. Credit where due: the format is declarative JSON with IML expressions rather than a code SDK, edited in the Make web interface or the VS Code Apps SDK, with CLI commands for building apps from the terminal, and their Make Skills table lists an API shell workflow skill that helps an AI "Build connectors that call third-party services directly from the command line", with Claude Code named in that table's "Best with" column (help.make.com/make-skills).
The unit of work is the hand-declared module: "There are six basic types of modules" (Action, Search, Trigger, Instant trigger, Universal, Responder), each declared against one endpoint pattern. Their documentation describes no route that derives module coverage from an API's spec; OpenAPI-to-app generation appears in Make's material only as a community feature request. And their own module rule concedes the ceiling on authored coverage: "Every app using API should have a universal module", the raw-call escape hatch for everything the authored modules do not reach.
The lifecycle carries published gates. Code inside a connector means custom IML functions: "Custom IML functions are not available by default. Contact us via our helpdesk", capped at a 10 second timeout, 5,000 characters, JavaScript built-ins and Buffer only. Public listing waits on Make's review (a universal module with a non-relative path "won't be approved by Make"), and once an app is published, "it is not possible to delete any module or component"; the documented remedy for a mistake is renaming it "[DO NOT USE]".
Five integrations clear their vendor portal paperwork in one afternoon, with the credentials landing straight in the vault instead of a spreadsheet. Elsewhere, on standard plans, sending credential requests is Partner or Enterprise upon request, and your customer joins your Make organization to answer one
Open the scenarioOnboarding stalled for days on OAuth paperwork before a single record moved.
Brightline, a B2B SaaS company, is launching integrations with five systems this quarter. Each of the five requires Brightline to register an application on that vendor's developer portal first: create the account, fill the forms, describe the use case, set callback URLs, wait, copy the credentials somewhere safe. It is nobody's job, so it becomes the bottleneck for everybody's job.
Five portals, one afternoon, zero credentials in a spreadsheet.
Collecting a customer's credentials without a screen-share exists on Make, behind a gate on the sending side, and the flow routes your customer into Make itself. Their credential requests feature is real and agent-drivable (their own skills repo documents "credential_requests_create (returns auth URL) -> user completes auth -> poll credential_requests_get"), and stored credentials are handled properly: keychains "prevent exposure of keys" and allow "easy and safe key rotation."
The gate is published, and it falls on sending rather than answering: "This feature is available to official Make Partners and Enterprise customers upon request. To enable it, each user needs to submit a form. Receiving and authorizing requests is available to all users." So on the plans in the pricing table, the route for onboarding customer credentials at scale is not a plan toggle; it is Partner status or an Enterprise contract, requested user by user. The documented alternative is the White Label instance, an OEM engagement "implemented by Make" with no published price.
And on the standard route the customer does not stay inside your product. Their documentation states that "Recipients can use this link to join your Make organization with a Guest role, with permissions limited to providing and managing the requested connection credentials." A customer who authorizes a connection this way holds a role in your vendor's system, which is the onboarding surface your customer was never supposed to see.
An onboarding call maps forty-one custom fields and a dropdown their admin invented, because the connector reads the customer's live tenant. Elsewhere, live field discovery runs where an app author built the RPC, under a 40 second cap
Open the scenarioField mappings built against documentation break on contact with a customer who renamed things and added forty custom fields.
A 60-store outdoor retailer is onboarding onto a loyalty integration. Their CRM has been customized for nine years: forty-one custom fields, two renamed objects, and a "member tier" dropdown whose values exist nowhere in any documentation, because their admin invented them. The mapping screen has to show their CRM, not the CRM in the manual.
The onboarding call maps forty-one custom fields without a single "we'll get back to you."
Make can read a customer's live system while a mapping is being built, and that deserves a plain concession: "Remote Procedure Calls are used to retrieve live data from a service for an input field." and "These requests are invoked while the user interacts with the modules when building a scenario." "Dynamic fields RPCs generate dynamic fields inside a module." "Dynamic options RPCs dynamically fill the fields in a module." Renamed fields and custom fields show up as typed inputs, inside apps built to do it.
That last qualifier is the cost, and it is narrower than a tier line. RPCs are components an app author implements, per field, per module, and a field without one is a static field. The fallback tier is not excluded from them by rule, and their own pages say so: "Components of the universal module are the same as for the action module", and on mappable parameters, "You can use Remote Procedure Calls (RPCs) to generate parameters dynamically." The generic HTTP module derives a shape too, by running: "Parse response: select yes to structure the output data so that it's easy to map. All mappable items will be available after you run the module once" (https://apps.make.com/http, seen 2026-08-26). What the fallback tier documents is the request rather than the record: on the universal module the endpoint path is the builder's to supply, "so users can copy-paste the endpoint path from the service documentation", and on the HTTP module the structure comes back after a call has already been made. The forty renamed custom fields this row is about arrive as typed inputs where an app author wrote the RPC that fetches them.
The ceilings on discovery are published and matter on exactly those accounts: an RPC runs under a 40 second Max Execution Timeout, with a recommended limit of 3 calls performed by RPC and 3 pages of paginated records, and "You must define a limit to the output if the API endpoint returns a large number of items (>500)". Field types are hand-converted to Make's types: "Properly convert field types between your service types and Make types. One of the ways to resolve it is to use custom IML functions." (https://developers.make.com/custom-apps-documentation/app-components/rpcs/dynamic-fields-rpc, seen 2026-08-26), and those custom IML functions are the helpdesk-gated ones.
Every API gets a vetted way of announcing changes, so records stop going missing or arriving twice. Elsewhere, unattached hooks answer 410 Gone after 5 days, and a full queue rejects incoming events
Open the scenarioEvery vendor's API announces change differently, and picking the wrong mechanism means missed or duplicated records.
Nine carrier systems, 1,400 load tenders a night. One feed replayed a status it had already sent and two trucks went to the same dock, so the night dispatcher now reconciles the tender log by hand.
Polling for new records, polling for new-or-updated, manual webhooks, self-registering webhooks, service webhooks with event filtering, and long-lived protocol listeners. Six vetted patterns; the AI picks the right one per API.
Make covers the mechanisms, and that should be said plainly: "Make supports the following types of webhooks: App-specific webhooks ... also called instant triggers. Custom webhooks allow you to create a URL to which you can send any data", and "If an app does not provide webhooks, you can use polling triggers to periodically poll the service for new data." Scheduled processing with per-webhook queues is documented too. The mechanism menu is not where this row is decided. What costs you is what their documentation says happens at the edges, because both edges lose events. On the unattached side, and it is unattached rather than merely quiet: "Make automatically deactivates webhooks that are not connected to any scenario for more than 5 days (120 hours). The hook return 410 Gone status code." On the busy side, queues are capped at 667 items per 10,000 monthly credits with a hard maximum of 10,000, and "When the webhook queue is full, Make rejects all incoming webhook data which is over the limit." For the polling fallback, the floor is the schedule: the pricing row "Minimum interval between scheduled scenarios Minimum time (in minutes) between scheduled scenario executions." reads 15 | 1 | 1 | 1 | 1 across Free, Core, Pro, Teams and Enterprise (https://www.make.com/en/pricing, seen 2026-08-26), so the freshness of a polling integration is bounded by the plan's clock.
Ask the AI for an inference or a price calculation and it arrives as a step your team can open and check. Elsewhere, the raw call is always available, and it hands you the request: the endpoint path is yours to supply and the output shape arrives after a run
Open the scenarioCreate-read-update-delete alone cannot express what modern APIs do.
The photo-damage model and the fraud score in claims intake sit inside a code block whose author left in March. At 3,000 claims a month, adjusters quote repair numbers the company cannot account for.
Add, delete, find, get, list, update, and invoke: the last one models operations that compute, transform, or generate (an AI inference, a price calculation), so the whole modern API surface fits the data model.
The call you can always make on Make is the one that hands you the request instead of the record. Inside an authored app, the escape hatch is the universal module: it can "perform an arbitrary API call to the service's API", and "It allows the user to specify all parameters of the request while using the app's connection", the iterate directive is excluded, and "An app can have only one universal module." Concede what it is not, because their own page is explicit: it is a declared module like any other. "Components of the universal module are the same as for the action module", so its fields are typed mappable parameters, and Make's mappable parameters page states "You can use Remote Procedure Calls (RPCs) to generate parameters dynamically." What gets declared there, in Make's own naming convention, is the request rather than the object: "Module label: Make an API call", "Module description: Performs an arbitrary authorized API call.", and a URL text field whose guidance reads "Expected input from users should start with / (for example /tasks) so users can copy-paste the endpoint path from the service documentation." The person building the scenario is reading the vendor's API reference at that point. Off the authored surface entirely sits the generic HTTP app, in Make's own framing for services "that don't have an integration with Make." It is a capable client (auth keychains, mutual TLS, native pagination in four declared types), and it does derive a shape, which we concede rather than deny: "Parse response: select yes to structure the output data so that it's easy to map. All mappable items will be available after you run the module once", and a JSON body can be built from a data structure whose generator is documented as "By providing a data sample, the generator will automatically create a data structure based off of the data sample you entered." (https://help.make.com/data-structures, seen 2026-08-26). The shape therefore arrives from a call already made or a sample already pasted; the fields the module itself documents are the properties of an HTTP request, URL, method, headers, query parameters and body. Pagination is configured per endpoint from "the service's API documentation", and the item ceiling is theirs: "you can also use this field to return items beyond Make's 3200 limit", a manual offset workaround for a 3,200-record cap. Error semantics thin out the same way. App modules map HTTP statuses to the typed errors that drive Make's automatic retry classes; the HTTP module offers a boolean, "Return error if HTTP request fails", plus a 1 to 300 second timeout and at most 10 redirects. The modern API call is reachable on day one; the per-operation typed inputs and the retry-classified errors exist where someone authored a module for them.
Ask the AI to set the vendor's limit, or type it once yourself, and every account sharing that API queues against one 185-calls-per-10-seconds budget. Elsewhere, pooling a vendor limit across accounts is design work, not a setting
Open the scenarioA vendor's rate limit is the real constraint on a multi-location sync, and hitting it corrupts a run.
310 branches sync to one supplier API that allows 120 calls per 10 seconds. A rate-limit rejection killed the nightly refill batch partway through, and branch queues opened at 8am short of data.
Type a vendor's limit once and the platform enforces it across every automation and every account that touches that API, with queueing and backoff. One deployment runs 232 locations against a single 185-calls-per-10-seconds budget with the platform queueing and backing off rather than each flow deciding on its own.
When two hundred locations share one vendor API, that vendor's rate limit is a budget someone has to enforce across all of them. Make's documented rate limit points the other way: it protects the scenario from inbound traffic, not the vendor from your fleet. 'Set a scenario rate limit to prevent scenarios with instant triggers from running too often in a short period ... The default scenario rate limit is 100', and callers over the line get 'HTTP 429 Too many requests' (help.make.com/schedule-a-scenario). When a vendor does throttle you, Make's published remedy is after the fact: RateLimitError is one of the three error classes Make retries automatically, on a fixed backoff schedule (help.make.com/automatic-retry-of-incomplete-executions). That is recovery from a limit already hit, not enforcement of a budget before it is hit. Make does not document an outbound rate-limit budget shared across multiple connections or accounts. We searched help.make.com/schedule-a-scenario, help.make.com/fix-rate-limit-errors, the HTTP app's advanced settings (apps.make.com/http), and the custom apps base and communication reference. On that basis, pooling one vendor's rate limit across many customer connections is manual work, spacing schedules and placing retry handlers per scenario, rather than a platform behaviour.
Integrations your team hand-built years ago become AI-editable without a rewrite. Elsewhere, maia edits the scenario in front of her; every headless edit sends the whole blueprint
Open the scenarioYears of existing integrations would otherwise be stranded outside the AI's reach.
214 integrations built by hand over eleven years, and the two people who built them are one retirement and one resignation from being gone. Modernizing cannot pause a single member-facing flow.
Integrations built by people over a decade convert into the same structured form the AI operates, so the AI can maintain the estate you already own. Nothing is stranded, and nothing loses its visual form in the process.
If your decade of integrations lives in Make, their AI can edit it; the reach per edit is one open scenario, with you carrying the context. Concede what is real: Maia 'creates scenarios, modifies existing ones, and fixes errors for you using your prompts', MCP management tools 'view and modify scenarios and their related entities', and Module Migrator 'detects deprecated modules, upgrades, and provides warnings and instructions for manual fixes' (release note, 2026-04-15). Work built outside Make joins that world by pasting blueprint JSON. The boundary sits on Maia's own page, updated 12 Aug 2026: she 'can't view execution logs from past scenario runs', so 'you must explain the error to her yourself', and she 'can't view other scenarios'; she can see the execution log of a run triggered with Run once. The AI edits what is open in front of it, and re-learns the rest from you each session. Headless, the write unit is the whole artifact: the API sends 'the blueprint ... as a string, not as an object' (developers.make.com scenarios API), and Make's own published AI skill instructs 'Call scenarios_deactivate on the scenario. Call scenarios_update with the corrected blueprint. Call scenarios_activate to re-enable' (integromat/make-skills, seen 2026-08-26). An agent's edit to a live scenario is a full-blueprint replace around an offline window their own skill prescribes.
Time-to-new-connector is measured in working sessions, not sprints, and every connector you add, however obscure the API, joins the same inspectable library instead of adding one more codebase to the pile someone must maintain.
Branching, routers, filters and subscenarios are documented on all plans, so those rows are deleted rather than argued. What survives is bounded by published numbers: a wait longer than the run becomes two scenarios and your own state, because the run ceiling reads 5 | 40 | 40 | 40 | 40 minutes across the plan columns and no suspend-and-resume primitive is documented, and custom code is metered ("2 credits per 1 sec of code execution time") or gated ("Custom IML functions are not available by default. Contact us via our helpdesk").
Field-to-field mapping is the demo. The business is nested rules, parallel work, digests, approvals, waits, and the awkward requirement that makes your operation yours. The question for any platform: does that logic fit inside the model, where it stays visible and testable, or does it spill into code and patterns your team hand-builds?
214 stores get overnight prices in minutes, and the 6am report fires once. Elsewhere, the all-finished signal is yours to build
Open the scenarioProcessing two hundred locations in series took hours. In parallel, nothing knew when all of them had finished.
Launch N child runs in parallel, and the platform itself knows when the last one completes, so the "everything is done, now reconcile" step is a primitive, not a science project.
A 214-location convenience chain pushes overnight price updates. Every store must be updated in parallel (serially it takes past opening), and when the last store finishes, one reconciliation report must go to the merchandising director, listing any store that failed. The hard part was never the fan-out. It is knowing, reliably, that all 214 are done.
Prices land in minutes, the report is on the director's desk at 6am, and nobody wrote coordination logic.
Make documents the fan-out; the join at the end is yours. 'Parallel scenario execution: Process multiple items simultaneously' is a pricing-table feature, 'scenarios with instant webhooks are processed in parallel' (help.make.com/webhooks), and an asynchronous subscenario call 'continues immediately without waiting for outputs' (help.make.com/subscenarios).
Those are also the terms of the trade. A synchronous subscenario call 'pauses execution until the subscenario completes', which is serial, and a parent that waits lives under the published run ceiling: 'Maximum scenario execution time (minutes) ... 5 | 40 | 40 | 40 | 40' (make.com/en/pricing). Asynchronous calls return no outputs to the parent.
Make does not document a fan-in: a mechanism by which a parent knows that N asynchronously launched subscenarios have all finished. We searched help.make.com/subscenarios (calling modes and managing scenario chains), help.make.com/scenario-execution-cycles-and-phases, and the Scenarios app documentation. On that basis, the all-finished signal after a parallel fan-out is manual work, for example counters kept in a data store, rather than a platform behaviour.
Contact changes flow both ways on day one, without the overnight loop that rewrites one record 4,000 times. Elsewhere, loop protection is a filter you write and maintain per sync
Open the scenarioTwo systems updating each other trigger each other, forever.
Arrowe Physio, 22 clinics. Patient contact details must stay identical in the practice-management system and the marketing CRM, editable from either side. The failure mode is famous: the CRM update fires a webhook, the integration writes to practice management, which fires its webhook, which writes to the CRM, which fires again. By morning one patient record has been "updated" four thousand times and both APIs have rate-limited the clinic.
The sync runs both directions on day one, and "infinite loop" is not in the runbook.
Two systems that update each other will re-trigger each other unless something recognizes its own echo. Make does not document echo suppression or update-loop protection for bidirectional sync. We searched the scenarios and data-and-mapping sections of help.make.com, help.make.com/webhooks, the scenario settings and error-handling overview pages, and the 2026 release notes index. On that basis, keeping a two-way sync out of a trigger loop is manual design work, filters comparing timestamps or marker fields that you write and maintain for each pair of scenarios, rather than a platform behaviour.
A loop that does get away from that filter runs against published buffers: 'When the webhook queue is full, Make rejects all incoming webhook data which is over the limit' (help.make.com/webhooks).
Customers get one 5pm summary instead of 400 pings, and nothing is lost when two runs land at once. Elsewhere, the digest is a scenario you build over a capped queue
Open the scenarioCustomers wanted one daily digest, not four hundred notifications.
One Tuesday produced roughly 400 emails, and two of the largest accounts asked to be removed from notifications. The operations manager assembles the 5pm digest by hand, and she is away next week.
Four hundred events land all day; one clean summary goes out at 5pm. A dedicated primitive, safe under concurrency.
The parts of a digest are documented; the digest is not. Scheduled webhook processing holds work back ('requests accumulate in the queue until the schedule criteria are met', help.make.com/webhooks), aggregator tools exist, and data stores can hold the day's items ('You can use up to 1,000 data stores per single organization', make.com/en/pricing FAQ). The buffer doing the accumulating has published edges: 'For every 10,000 credits licensed per month, you can have up to 667 items in each webhook's queue. The maximum number is 10,000 items in the webhook's queue. When the webhook queue is full, Make rejects all incoming webhook data which is over the limit' (help.make.com/webhooks). A digest that buffers a busy day lives inside those numbers. Make does not document a digest behaviour, for customer notifications or for its own alert emails, whose documented controls are three organization-level toggles (Deactivation, Warning, Errors). We searched help.make.com/manage-your-email-preferences, the error-handling overview, the webhooks scheduling documentation, and the 2026 release notes. On that basis, one daily digest instead of hundreds of notifications is a scenario you design, build, and maintain rather than a platform behaviour.
A three-day follow-up needs one system, not a separate scheduler for somebody to own. Elsewhere, waits longer than a run become two scenarios and your own state
Open the scenario"Follow up in three days" required an external scheduler and a second system to maintain.
If the adjuster has not followed up within three days, the claim ages into a regulatory bucket with a penalty. The scheduler holding that wait missed 34 follow-ups, and the audit is in November.
A run can suspend itself for three days, or until next quarter, and resume with its state intact. One system, one place to look.
'Follow up in three days' does not fit inside a Make run. The published ceiling: 'Maximum scenario execution time (minutes) ... 5 | 40 | 40 | 40 | 40' (make.com/en/pricing), forty minutes on every paid plan including Enterprise, and their troubleshooting documentation adds that 'most Make modules have a runtime limit of 40 or 60 seconds' (help.make.com/fix-errors-and-warnings). A Sleep tool exists for short pauses. A multi-day wait therefore cannot be a paused run; it has to be decomposed. One scenario writes state somewhere, a schedule or webhook starts a second one days later, and the state store, the trigger, and the correlation between them are yours to design and keep correct. Make documents no suspend-and-resume primitive; when we looked, the Tools documentation page itself returned 'This page is coming soon' (apps.make.com/tools, 2026-08-25), and neither help.make.com/schedule-a-scenario nor the subscenarios documentation describes one.
Refunds over $500 wait for a manager's approval while everything else keeps moving. Elsewhere, the approval hold is a build, not a feature
Open the scenarioSome records must not sync until a person says yes, and the wait cannot block the platform.
After £48,000 of refunds in one night, anything over £500 needs a venue manager to say yes. Those requests now sit in a shared inbox chased by text, while every small refund queues behind them.
A run pauses on a queue; a person approves or denies from a link; the run resumes. Refunds over $500 wait for a manager, everything else flows.
Some records must wait for a person, and the wait cannot live inside a run that is capped at 40 minutes on paid plans. Make does not document a human-approval or moderation-queue primitive. We searched the Tools and scenarios sections of help.make.com, the apps.make.com built-in apps list (no approval app is listed there), the 2026 release notes, and the subscenarios documentation. On that basis, holding a record until someone says yes is manual work, typically a data store holding the pending record plus a second scenario triggered by the approval, rather than a platform behaviour. That build inherits the properties of its parts: the pending queue is a data store you size and manage, the approval surface is something you construct, and everything that resumes the flow is a scenario you wire and test yourself.
A customer's 300-row mapping sheet becomes the configuration directly, with unresolved rows flagged, instead of a week of error-prone typing. Elsewhere, each mapping row is typed in, or scripted as a whole blueprint
Open the scenarioA customer's mapping requirements arrived as a 300-row spreadsheet, and hand-entering it was a week of error-prone work.
The field map arrived as a 300-row spreadsheet, and hand-keying it eats most of week one of four. Every keying slip surfaces later as a subscriber billed twice, and renewal season opens 1 October.
The 300-row file becomes the mapping, directly. The AI reads it, applies it, and flags the rows that do not resolve.
A 300-row mapping spreadsheet arrives, and someone has to type it in. Make does not document a way to import a mapping spreadsheet or CSV and produce working field mappings from it. We searched the data-and-mapping section of help.make.com, the data structures page (help.make.com/data-structures), the Maia documentation, and the 2026 release notes. On that basis, turning a customer's mapping sheet into live mappings is manual work, hand-entering each row in the builder or prompting Maia through them, rather than a platform behaviour. The programmatic alternative is the blueprint itself: mappings live inside the scenario blueprint, which the API accepts as one string, 'sent as a string, not as an object' (developers.make.com scenarios API). A script that writes 300 mappings writes the entire scenario.
Turnover stops costing you the same debugging twice: a quirk solved once stays solved after its author leaves. Elsewhere, the lessons stay with your engineers, not the platform
Open the scenarioThe same API quirk was rediscovered every time, by whoever drew the short straw.
The engineer who holds the loan-status lookup table in his head has given notice. 11 live integrations rest on knowledge that was never written down, and his replacement starts in three weeks.
Mappings, transforms, gotchas, and templates are saved and searchable. The AI checks the library before building, so the Mindbody pagination quirk gets solved once, ever.
The tenth engineer meets the same API quirk as the second, because the platform does not hold what the second one learned. What Make's AI consults is Make knowledge: Make Skills are 'markdown files (.md) with reference information, best practices, and instructions on Make-specific topics' (help.make.com/make-skills), platform-generic by design. The writable knowledge store that does exist, the AI Agents Context API (open beta, seen 2026-08-26), attaches 'files stored in the agent's memory' to a deployed Make AI Agent, the runtime product; nothing writable feeds Maia, the MCP management tools, the CLI, or the skills. Maia herself starts each job without your history: 'She can't view other scenarios' (her page, updated 12 Aug 2026), and chat sessions are stored for 15 days. Make does not document a platform-level store of customer-specific integration lessons that the build AI consults. We searched skills.make.com, help.make.com/make-skills, the MCP server tool descriptions, and the Maia documentation. On that basis, carrying an API quirk forward to the next build is manual work, kept in your team's own notes, rather than a platform behaviour.
A genuinely odd requirement ships without waiting on a vendor release, and everything around it stays readable. Elsewhere, custom code is metered per second, plan-gated, or helpdesk-gated
Open the scenarioOccasionally a requirement is genuinely outside any data model, and waiting for a platform release is not an answer.
A 1987 mainframe demands a check digit no mapping tool expresses. The systems analyst has a 30 September council deadline and a $140,000 quote for middleware to cover that one field.
When you truly need arbitrary logic, a script slots in as one node of the structured document. Code is an optional leaf inside a data document, never the foundation. Everything around that leaf stays visible, testable, and machine-editable.
The escape hatch exists on Make, and every route to it carries a meter or a gate. The Make Code App runs 'custom JavaScript or Python in Make to add advanced logic, transform data, and power AI-driven workflows' from the Core plan up, metered at '2 credits per 1 sec of code execution time' (https://www.make.com/en/pricing, seen 2026-08-26). The separate Custom functions feature, reusable custom JavaScript functions inside scenarios, sits on the Enterprise plan: 'Everything in Teams, plus: Custom functions support.' Built-in IML function modules are a different thing and ship on all plans. Inside a connector, the same pattern holds: 'Custom IML functions are not available by default. Contact us via our helpdesk if you need to create a custom IML function.' (https://developers.make.com/custom-apps-documentation/app-components/iml-functions, seen 2026-08-26), with published caps on the same page of 5,000 characters, 'Only JavaScript built-in objects and Buffer are available for you to use,' and a 10-second Max Execution Timeout. Code is reachable at every level of the platform, and at every level the reach is metered per second of execution, gated to a plan, or opened by a support ticket.
Logic complexity does not convert into code ownership. The awkward rules that make your business yours stay inside a model that your people can read, your tests can cover, and your AI can safely change.
Replay on real production data is documented on all plans, and both of those rows are deleted. The bounds are the argument: replay "runs a current version of a scenario using trigger data from a previous run" inside a 7-to-60-day window, "Bulk replay is currently not possible", and a private or public custom-app edit has no staging step, since "All changes take effect immediately in running scenarios with private and public custom apps" and a JavaScript syntax error means "all scenarios that are using the app will throw the error message about JavaScript syntax and will be stopped immediately." Approved catalog apps are the documented exception and we concede them: commit, per-change diff files and a rollback endpoint, at the cost of Make's manual review on every released change.
"It worked when I tried it" tests one path out of eleven. The other ten are where customers live. This act is the answer to the third standing test: when the AI, or a person, gets something wrong, what in the architecture catches it before production data does?
Prove a path that fires once a year works today, not in nine months. Elsewhere, replays what production already produced, inside the log window
Open the scenarioThe branch nobody could trigger on demand was the branch that broke.
United Harvest, a federation of 90 food banks. Their donation pipeline has a branch that fires only for tribute gifts carrying a matching-gift employer code, which in practice happens in the last week of December. It is March. The integration was just modified. The question: how do you prove the December branch still works, in March, without waiting nine months or faking an entire donation flow end to end?
The branch that used to be tested by December is tested by lunch.
When a rare branch has already fired in production, Make can re-run it. 'Run replay is a capability that runs a current version of a scenario using trigger data from a previous run' and 'run replay is available on all plans' (https://help.make.com/scenario-run-replay, page updated 25 Aug 2026, read 2026-08-26), and a standalone module test shipped in July 2026: 'test modules before connecting scenarios' (help.make.com/2026). Both are real and worth having.
The boundary sits in the same document. Replay uses 'trigger data from a previous run,' and their replay documentation does not describe editing or synthesizing that payload to force a branch that has not fired yet. A run is replayable 'as long as it's available in the history, which varies by plan': the pricing matrix puts that history at 7 days on Free, 30 on Core, Pro and Teams, and 60 on Enterprise. So the branch that has never fired, the one this row is about, has no stored run to replay, and the stock of replayable runs expires on a 7-to-60-day clock.
The AI tests every branch before it ships. Not the branches somebody thought to write payloads for. Every branch.
Ship a one-line fix across 300 accounts knowing exactly which customers it touches. Elsewhere, mapped inside your org; a connector fix lands on every scenario using the app at once
Open the scenarioA one-line connector fix silently changed behaviour for three hundred accounts.
Beacon, a B2B SaaS vendor with 300 customer accounts live. A date-format bug is found in a shared connector operation. The fix is one line. The question that separates a routine Tuesday from an incident: which automations call this operation, on which customers' accounts, and which of them are relying on the buggy behaviour without knowing it?
The one-line fix ships with a printed list of everyone it touches, so the dependents are known before the edit rather than after it.
Inside one organization, concede this row's mechanics: 'Make Grid helps trace data flows and identify inter-scenario dependencies and impacts before making changes' (help.make.com/introduction-to-make-grid), and Grid content search 'scans all scenario configurations to find modules, field IDs, URLs, notes, AI prompts, and dependencies' (help.make.com/2026, 8 Jul 2026). That is a genuine dependency map with search, and the right tool for the question within your own account.
The row asks about customers, and there the propagation runs ahead of the visibility. A fix to a shared connector (a custom app) is instant and total: 'All changes take effect immediately in running scenarios with private and public custom apps. You should take this into account while changing your code.' (https://developers.make.com/custom-apps-documentation/app-maintenance/updating-your-app, seen 2026-08-26), and the private and public apps page sizes the blast radius of a JavaScript syntax error: 'Otherwise, all scenarios that are using the app will throw the error message about JavaScript syntax and will be stopped immediately. This affects all scenarios even if they run app modules that do not contain the faulty custom IML functions.' (https://developers.make.com/custom-apps-documentation/app-maintenance/updating-your-app/private-public-apps, seen 2026-08-26).
Where customers run per-team scenario copies, Grid enumerates your organization's scenarios. Make Managed Services, their distributor structure, manages child organizations through four documented endpoints, none touching scenarios (developers.make.com MMS API, seen 2026-08-26). On Enterprise, dynamic connections invert the model: one scenario serves N customer connections, so a fix is one edit, and the answer to 'which customers does this touch' is every one of them, on their next run.
You know a change is fully tested because the platform counts untested paths, not because someone felt confident. Elsewhere, path coverage is bookkeeping your team keeps by hand
Open the scenario"It worked when I tried it" tested one path out of eleven.
The claim-intake automation has eleven branches. The claims supervisor signed off on a mapping change because the hail path ran clean in test. Harvest starts in five weeks and ten were never walked.
The platform knows every branch an automation has and tracks which ones testing has actually exercised. Coverage is measured, not assumed. A change ships when the walk is complete.
Make does not document this. We searched the run replay and scenario history documentation (help.make.com/scenario-run-replay, help.make.com/scenario-history), the Make Grid pages, skills.make.com, and the full 2026 release-notes index (help.make.com/2026, January through August 2026). On that basis, knowing which routes of a scenario have been exercised is manual bookkeeping rather than a platform behaviour. What is documented nearby is build-time validation: their own skills prescribe validate_blueprint_schema and per-module configuration checks before a scenario is created ('Every module is validated individually via the MCP API before blueprint assembly,' https://skills.make.com, seen 2026-08-26). That gates whether a blueprint is well formed, which is a different question from whether path four of eleven has ever run.
Answer a month-old complaint by re-firing the exact message that failed. Elsewhere, completed runs replay one at a time, inside a 7-to-60-day window
Open the scenarioTesting a webhook-triggered flow meant asking a customer to go and click something in their system.
An undocumented rate-confirmation payload began dropping accessorial charges worth 18,000 euros a week. The fix is written. Validating it means asking a shipper to re-tender loads they already moved.
Every webhook ever received is a test case. Re-fire last month's payload against the fixed automation and watch it process, without asking a customer to reproduce anything.
'Last month' collides with two published lines. Their replay page states: 'Bulk replay is currently not possible. A run is replayable as long as it's available in the history, which varies by plan' (help.make.com/scenario-run-replay, updated 25 Aug 2026). The pricing matrix sets that history at 7 days on Free, 30 on Core, Pro and Teams, and 60 on Enterprise, so on most paid plans a run from five weeks ago is already gone. The endpoint matches the page: the replay API accepts an array of executionIds but documents that 'Currently only the first one will be replayed,' one call per run (developers.make.com, scenarios API). To keep the picture fair, bulk retry does exist for incomplete (failed) executions, with a 'Retry selected' button and an API call scoped to a single scenario; the not-possible line is about re-driving completed traffic, which is exactly what re-running last month's live webhooks means.
An agent works production with full read, and the actions that reach a fleet return a plan a human approves. Elsewhere, write caution is a client-side annotation, not a platform gate
Open the scenarioThe fastest way to an outage is a confident agent with production credentials.
An AI agent is to work directly on production integrations posting 2,600 ACH transactions a night. One mis-sequenced deploy at 11pm is a reportable incident by the time branches open.
The AI inspects production freely and changes nothing without an explicit, human-confirmed deploy step. Autonomy without the blast radius.
The read/write split is set when the agent connects, and the caution on writes is delegated to the agent's client. 'The scopes available to you depend on your plan: users on all plans can use scenario run scopes, and those on paid plans can use management scopes.' and 'You select scopes when you connect to an MCP client, either in an OAuth consent screen or MCP token dialog.' (https://help.make.com/make-mcp-server, seen 2026-08-26). MCP toolboxes refine this per toolbox with Read only and Read & write tool annotations: 'In MCP clients that support them, annotations help clients understand how cautious to be with a tool, such as asking for permission before running it' (https://help.make.com/mcp-toolboxes, seen 2026-08-26). That is a workable model, and the narrowing matters: once a management scope or a Read & write toolbox is granted, their pages delegate per-tool caution to the MCP client via those annotations rather than documenting a Make-side approval step on writes. Whether a write pauses for a human depends on which client the agent happens to run in, not on the platform the write lands on.
Test coverage is a property of the platform, not of your team's imagination for payloads. Across months of daily production builds on APIANT, no hallucinated mapping, structure, or logic has been observed reaching production. That is what the compiler and the branch walk are for.
Concede the architecture up front: Enterprise dynamic connections let one scenario select its connection per run, so a vendor can serve many customers from one scenario, and subscenarios propagate a single edit to every parent inside a team. Past that team wall it is copies, because "All of these items always belong to only one team", and we found no bulk deploy or update endpoint in the scenarios API, the CLI reference, the MMS endpoints or the White Label documentation: every scenario call takes one scenario ID and one blueprint, MMS manages child organizations by creating, allocating credits, pausing and unlinking rather than by deploying, and the one documented batch verb, POST /dlqs/retry, retries incomplete executions of a single scenario with the old blueprint. A fleet push is a rate-limited loop you write.
Building the integration once is the demo. Running it for three hundred customers, each configured differently, each on their own credentials, all needing the same fix on the same day, is the business. This act is where per-customer platforms and per-fleet platforms part ways.
Ask the AI to ship the fix and it deploys to 232 linked accounts on your confirmation of the plan it returns. Elsewhere, on the plans in the pricing table each customer is a separate copy; the Enterprise exception swaps only the connection
Open the scenarioEvery customer wants the same integration configured differently, and cloning it per customer creates hundreds of divergent copies.
One codebase carries the logic. Settings (which fields sync, which features are on, time zones, branding) vary per customer. The same automation serves a single-location studio and a 232-location franchise.
A fitness franchise with 232 locations runs a booking-system-to-CRM integration at every site. Each location has its own booking credentials and its own quirks (time zones, membership names, feature toggles), but the logic is identical everywhere. Today, a fix needs to reach all 232 before the evening class rush. This is a real deployment shape running on APIANT now.
Fix at 2pm, fleet-wide by 2:15, evening classes uneventful.
Every customer costs you another copy to keep current. On the plans in the pricing table, Make's documented multi-customer routes are per-copy: a blueprint is "a reusable version of a scenario" that each customer imports, and their own page adds, "While blueprints include scenario modules, settings, and mapped values, users still need to create connections for their accounts after importing the blueprint" (help.make.com/blueprints). API cloning is per target team: "If you are cloning a scenario to a different team, you have to map the scenario entities (connections, data stores, webhooks, ...) from the original to the clone" (developers.make.com scenarios API).
Per-customer settings do not survive an update. A blueprint "includes: Scenario modules, Module settings, Mapped values," so re-importing a corrected master replaces the copy's contents wholesale, and any customization made inside a customer's copy is overwritten by the master's values. We searched help.make.com/blueprints and scenario-templates, the scenarios and templates sections of the API reference, the MMS endpoints and the White Label documentation on 2026-08-26, and none of them publishes a mechanism that keeps many copies pinned to one master version while preserving per-customer configuration.
Make's real alternative is architectural, and it is conceded here: on Enterprise, "A dynamic connection is a variable that contains a connection. It allows you to choose which connection a module uses in a scenario run ... This feature is available to Enterprise customers" (help.make.com/dynamic-connections). One scenario can then serve many customers, which is the documented exception to the per-copy routes above, but it swaps the connection per run, not per-customer field mappings or settings, and it requires holding every customer's credentials in your own team.
One incoming request lands in the right location's account, on that location's own credentials, with hundreds of accounts behind the curtain. Elsewhere, teams are walls, and the parent's documented verbs are billing, not work
Open the scenarioThree hundred locations cannot each hold their own credentials and configuration.
Kestrel Pharmacy Group's 178 branches share one refill endpoint, with the store code buried in the payload. The first batch lands at 6:40am, and every message has to reach the branch that can fill it.
A parent account governs hundreds of children. A webhook hits the master, which routes by location to the right child, which processes with its own credentials. The caller never knows there are 232 accounts behind the curtain.
There is no parent that routes work downward; there are containers with walls. Make's structure is organizations holding teams, and the team is the wall: for scenarios, connections, webhooks, data stores, data structures and custom functions, "All of these items always belong to only one team. You can't change which team a particular item belongs to" (help.make.com/teams). Below the Teams plan the structure collapses further: "you can only have one team in your organization." The closest thing to a parent-child hierarchy is Make Managed Services: it "lets distributors of Make manage multiple organizations under a single entity ... Create child organizations, Allocate and adjust credits across child organizations, Assign ownership, Pause child organizations, Unlink child organizations" (help.make.com/make-managed-services-mms). Those verbs are licensing and credit allocation. The MMS API publishes four endpoints for child organizations, and none of them touches a scenario, a connection, or a run (re-verified 2026-08-26). So a parent can bill its children and pause them; what its documented verbs never carry is the per-customer configuration and the work itself. The Enterprise architecture that does hold many customers' credentials in one place, dynamic connections, works the other way round: the credentials sit in your team and the scenario picks one per run, so what is centralized is the connection, not the mappings and settings of three hundred locations.
One CRM login covers every location while each site keeps its own booking login. Elsewhere, credential sharing ends at the team boundary
Open the scenarioRe-authenticating per location does not scale past about twenty.
Southern Reef Dental's 96 practices each hold their own practice-management login, but the one group CRM token expires every 90 days. Re-authorising clinic by clinic has cost three weekends.
One CRM credential, flagged shared, serves all 232 locations, while each location keeps its own booking-system credential. Sharing is a toggle on the hierarchy, alongside shared settings and shared automations.
A credential serves the team it was created in and stops there. Within one team, reuse is real and conceded: a connection is usable by that team's scenarios, and "Replace connections across multiple modules: Replace connections in multiple modules of the same app across one or many scenarios" is a documented convenience (help.make.com/connections). On Enterprise, dynamic connections go further: one scenario chooses "which connection a module uses in a scenario run" (help.make.com/dynamic-connections), so a vendor holding all customer credentials in one team can serve many accounts from one scenario. The fleet pattern this row describes is different: one shared vendor credential of yours, alongside hundreds of separate per-customer credentials that stay isolated from each other. Their teams page states an item's team can never be changed, and the pages we searched publish no route that shares one connection between organizations (help.make.com/connections, /teams, /organizations and /dynamic-connections, plus the connections and MMS sections of the API reference, 2026-08-26). Sharing therefore ends wherever you draw the customer boundary: inside a team a connection is reusable and, on Enterprise, selectable per run, and across that boundary Make documents no way to move or share the credential, so the shared vendor credential is created again on the other side.
A week of hand-updating becomes one confirmed action, staged if you prefer, with every prior version kept for a redeploy. Elsewhere, no bulk deploy or update endpoint exists; a fleet push is a rate-limited loop you write
Open the scenarioShipping a fix to two hundred customers by hand takes a week and misses some.
A payment provider renamed a field overnight and refunds have been failing since 05:00. The head of support has the fix in hand and 186 venue environments to get it into before Friday's 10am on-sale.
Deploy or upgrade a codebase group across the fleet in one action, atomically, with staged rollouts when you want caution and instant rollback when you need it.
A fix reaches your customers one API call at a time, in a loop your team writes and owns. Make's unit of deploy is the scenario, welded to one team, and every documented scenario endpoint and every make-cli scenarios command takes one scenario ID and one blueprint (scenarios API reference and CLI reference, re-verified 2026-08-26). No bulk or batch scenario-update or deploy endpoint, no release or promotion object, and no staged rollout appears anywhere in the API reference, the CLI reference, the MMS endpoints, or the White Label documentation. The one documented batch verb, POST /dlqs/retry, retries incomplete executions of a single scenario, with the old blueprint. Templates seed new scenarios; republishing updates the template link, not scenarios already created from it: "Users who have the link to the previously published version will see the updates once you republish the template." Connector-level change is the exception, in both directions. Editing a custom app is a fleet-wide push: "All changes take effect immediately," with Make's own warning that one JavaScript syntax error means "all scenarios that are using the app will throw the error message about JavaScript syntax and will be stopped immediately" (developers.make.com custom-apps app-maintenance). Approved-app changes ship with documented commit, per-change diff, and rollback endpoints; for non-approved custom apps their advice is "no Diff tool available," export each version to GitHub yourself. Two Enterprise-team architectures narrow the problem and are conceded: dynamic connections let one scenario serve N customers by selecting its connection per run, and subscenarios propagate one edit to every parent scenario in the team ("Update the logic once, and all parent scenarios benefit automatically"). Neither carries per-customer settings together with fleet rollback, and a scripted loop over copies is bounded by the published API rate limits of 60 to 1,000 calls per minute by plan.
Ask the AI what changed and it diffs the bad version against the last good one; the reversal is a redeploy of that kept version to the fleet. Elsewhere, sixty days of scenario versions, no documented compare view, scenario rollback composed by hand
Open the scenarioA change made things worse, and there was no way back.
The night before enrolment week, the integrations lead changed how guardian contacts are matched. Registrars in six districts are seeing siblings collapsed into one record, and offices open at 07:30.
Every committed version is kept, any two versions diff against each other, and rollback restores a known-good state fleet-wide in one action.
You can go back, for sixty days, one scenario at a time, without a diff. "Version history lets you access and restore previously saved scenario versions for up to 60 days" (help.make.com/restore-and-recover-scenario), and the API enforces the same wall: "Due to the regular archiving process, only the versions that are not older than 60 days can be retrieved" (developers.make.com scenarios/blueprints). Versions are created on manual save, and no compare or diff view for scenarios is documented on any plan: the blueprints API ships exactly Get blueprint versions and Get scenario blueprint, and neither help.make.com/restore-and-recover-scenario nor the 2026 release notes index adds one (checked 2026-08-26). On the API there is no restore endpoint either; scenario rollback is composed by fetching an old blueprint and PATCHing it back onto the scenario yourself. At the connector level the record is split by approval status. Approved catalog apps get real versioning: documented commit, per-change diff files, and a rollback endpoint (POST /sdk/apps/{app}/{version}/rollback, seen 2026-08-26), sitting behind Make's review of every released change. For custom apps that are not approved, their own page states "it's not possible to keep track of changes as there is no Diff tool available," the documented advice is to export each version to GitHub yourself, and edits "take effect immediately in running scenarios." A scenario changed 61 days ago has no documented road back.
A new account is created, linked, and inheriting shared logins, settings and automations in one operation, with no onboarding checklist to work through. Elsewhere, onboarding is per-scenario API calls plus a Partner/Enterprise-gated credential flow
Open the scenarioOnboarding a customer was a manual checklist.
Twelve newly acquired hotels each need their management system talking to the group's revenue and CRM stack before the 1 October rebrand. The onboarding checklist runs 31 steps per property.
A new customer account is created, linked into the hierarchy, and inherits shared connections, settings, and automations immediately. Provisioning is an operation, not a project, and the AI can run it.
Onboarding a customer is a script your team writes, then maintains. The documented pieces exist and are quoted here as their route: create a scenario from a blueprint per team via the API, map entities per clone ("you have to map the scenario entities (connections, data stores, webhooks, ...) from the original to the clone"), and then the part no script can do for the customer: "users still need to create connections for their accounts after importing the blueprint" (help.make.com/blueprints). Collecting those credentials has a documented flow, and it is gated twice. Credential requests are "available to official Make Partners and Enterprise customers upon request. To enable it, each user needs to submit a form," and the recipient uses the link "to join your Make organization with a Guest role" (help.make.com/introducing-credential-requests). Your customer's first onboarding step is acquiring a role in the vendor's system. No single onboard-a-customer operation is documented on standard plans; we searched help.make.com/blueprints and scenario-templates, the scenarios and templates sections of the API reference, the MMS endpoints (child-organization creation covers licensing, not scenarios), and the White Label documentation, whose admin verbs are "Provisioning and managing end-user lifecycle" on an OEM instance. The scripted loop runs under the published API rate limits of 60 to 1,000 calls per minute by plan.
You ask the AI who is exposed and get the list in minutes. Elsewhere, grid answers for your organization; an install base beyond it has no query
Open the scenarioAn API deprecation notice arrived, and nobody knew who was exposed.
A carrier emails that v1 of its claims API retires in 90 days. By Friday the claims systems manager must name which of 74 connected systems touch that endpoint. That list does not exist.
The vendor emails "v1 of our API sunsets in 90 days." One query returns every automation and every account affected, which becomes the migration worklist.
The query exists, it is genuinely good, and its universe is your own organization. Concede it first: "Make Grid helps trace data flows and identify inter-scenario dependencies and impacts before making changes" (help.make.com/introduction-to-make-grid), Grid content search "scans all scenario configurations to find modules, field IDs, URLs, notes, AI prompts, and dependencies" (release note 2026-07-08), and Module Migrator "detects deprecated modules, upgrades, and provides warnings and instructions for manual fixes" (2026-04-15). For scenarios you can see, a deprecation notice is answerable. The boundary is the install base. Grid enumerates one organization's scenarios. Where your customers run as separate organizations, or as copies you shipped out as blueprints, no documented mechanism lists which end-customer organizations installed your custom app or imported your blueprint (searched: Grid documentation, custom-apps app-maintenance, White Label documentation, MMS endpoints, 2026-08-26). And when a breaking connector change does need to reach affected users, their documented route is a ticket: "Contact the help desk with a request for email notification to users."
Customer three hundred costs what customer three cost. Growth in breadth, more customers, more locations, does not multiply your operational surface, and does not show up as a per-deployment line item on the platform bill.
Bulk retry of incomplete executions and stopping a running execution are both documented, so those rows are deleted, and so is usage reporting: per-organization, per-run and per-scenario consumption reads are published. What is bought by plan: "Execution log storage (days) ... 7 | 30 | 30 | 30 | 60", automatic retry fixed to "RateLimitError, ConnectionError, ModuleTimeoutError" with everything else wired module by module, webhook queues capped at 10,000 items where "Make rejects all incoming webhook data which is over the limit", "Audit logs are available on the Enterprise plan only", organization analytics "available only for organizations with the Enterprise plan" and only to the Owner organization role, and a per-scenario usage endpoint that publishes the past 30 days.
Nobody buys an integration platform for month one. The purchase is really years two through five: the customer reports, the API drift, the 2am incidents, the person who left. Every platform demos the build. This act is about everything after the demo, which is where the money is, and where architectures stop being interchangeable.
Answer a three-week-old customer complaint before standup: find the run, fix it, prove it, ship to all 90 sites. Elsewhere, the run is findable for 30 days on most plans, 60 on Enterprise, then it is gone
Open the scenario"It did not work for this one customer last Tuesday" was a multi-day archaeology project, and often unanswerable.
6:51am, a support inbox. One location of a 90-site franchise writes: "A member signed up on June 30 and she never showed up in our CRM. She's furious. What happened?" It is July 21. Three weeks ago. The platform has run hundreds of thousands of executions since. Somewhere in there is one run that did something wrong to one record, and a customer is waiting to find out whether you are the kind of vendor who can answer.
All of it directed conversationally, by one person, before the 9:30 standup. The reply to the location: what happened, why, fixed, and here are the other three members we caught and restored.
The answer exists for as long as the log does, and the log is short. Make's pricing matrix publishes it as a plan row, "Execution log storage (days) Number of days that detailed execution logs are available." reading 7 | 30 | 30 | 30 | 60 across the Free, Core, Pro, Teams and Enterprise columns (https://www.make.com/en/pricing, seen 2026-08-26). A complaint about last Tuesday is answerable; the same question about six weeks ago is outside the window on every plan below Enterprise, and a run from more than two months ago is outside the published window on every plan.
Inside the window, the search tooling is real and tier-gated: full-text execution log search "lets you search for any term appearing in module outputs within the scenario execution history," and it is "Available on Pro and higher plans. If you upgrade from lower tiers, Fulltext search will only display executions that were run after the upgrade" (help.make.com/scenario-history). The search is invoked from one scenario's History tab, so a hunt across a fleet of customer copies is one scenario at a time. Replay of what you find is likewise bounded: "A run is replayable as long as it's available in the history, which varies by plan."
"It didn't work for one customer last Tuesday" stops being a week of archaeology. It becomes a conversation.
A real deployment went from 140 alerts a day to 3. Elsewhere, alert rules are on/off per notification type; thresholds, digests and routing are scenarios you build
Open the scenarioAlerting was either silent or so noisy that everyone stopped reading it, which is the same thing.
A platform team's alert channel gets 140 integration alerts a day. A hundred and thirty-eight are a flaky sandbox and a vendor's nightly maintenance window. Two are real. The humans did the rational thing months ago: they muted the channel. Last Thursday, one of the two real ones sat unread for nine hours while a customer's orders silently queued.
Three alerts a day, each one real, each one read. The channel gets unmuted.
Alert control is on and off, per notification type; everything between silent and noisy is a scenario you build. What exists is documented plainly: "Make can automatically send notification emails when your scenario encounters a warning, an error, or a deactivation due to errors," customizable "for each organization you belong to" through three toggles, Deactivation, Warning, Errors (help.make.com/manage-your-email-preferences). The API writes the same switches: PUT /users/{userId}/user-team-notifications/{teamId}/{notificationId} "Updates team notification settings for the user" with a body of {enabled}, under their own caveat that "you can only update notification settings for the user associated with the API key used for authentication," plus Mailhub preference endpoints PATCHing {id, enabled} (developers.make.com, seen 2026-08-26).
So enable and disable per notification type, per team, per user is the whole documented rule surface. No endpoint or documented setting exists for a threshold, a digest, destination routing, a suppression window, or a retryable-error list; we searched manage-your-email-preferences, overview-of-error-handling, the full API reference index, the CLI reference, and the make-skills repository at v0.1.7. Their documented in-flow fragment is per-module error handlers (Break with retry attempts and delay, Ignore, Resume, Commit, Rollback) authored into each blueprint. Turning four hundred notifications into one meaningful daily digest is therefore an automation the customer designs, builds and maintains, not a platform behaviour.
Ask once and 180 automations across a parent and 60 children are snapshotted and disabled, then restored exactly as they were. Elsewhere, shutdown is one call per scenario, and the what-was-on record is yours to keep
Open the scenarioWhen an upstream vendor breaks, the choice was between flooding a broken API and losing track of what to turn back on.
Tuesday, 11:40am: a CRM platform your customers depend on goes down hard. Across one parent account and its 60 child accounts, 180 automations are hammering a dead API, burning retries, and generating an alert storm. Every minute they keep running makes the eventual recovery messier. But some of those automations were off already, on purpose, and when the vendor recovers you must restore exactly the previous state, not "turn everything on" and reawaken the three that were disabled for good reasons.
Total human attention: minutes at the start, minutes at the end. No flood, no amnesia.
When an upstream vendor breaks, shutting down on Make is a loop, and knowing exactly what to turn back on afterwards is a record you keep yourself. The per-scenario controls are documented and we concede them: a scenario deactivates in the UI or by API, and their stop endpoint is described as "Deactivates and stops the specified scenario if the scenario is running." Reading the full scenarios API reference and the full make-cli reference on 2026-08-26, our finding is that every documented scenario endpoint and every CLI scenarios command takes one scenario ID; that sentence is ours, not theirs. Make Managed Services adds a distributor-level "Pause child organizations" verb, but its documented scope is licensing and credit allocation, not scenario state.
Make does not document a bulk disable of many scenarios in one action with a snapshot of their prior states and an exact restore. We searched the scenarios API reference, the Make CLI reference, the MMS endpoints, and the 2026 release notes. On that basis, an incident kill switch across hundreds of scenarios is manual scripting against per-scenario endpoints, run once to stop and again to restore.
The restore half is the sharper cost. Their own blueprint import documentation frames scenario state as per-copy, and we found nothing documented that records which scenarios were active at the moment you shut down. Turning back on exactly what was on before is therefore only as exact as the inventory your team wrote down while the outage was happening.
Transient blips retry themselves while broken credentials stop instead of hammering a customer's API, set once for the whole tenant. Elsewhere, automatic retry is fixed to three error classes; the rest is module-by-module handler wiring
Open the scenarioTransient failures were treated as fatal, and genuine auth failures were retried forever.
At 03:10 transient 502s marked 340 overnight freight tenders fatal, while an expired token retried until that carrier's account locked. Trucks unassigned past 07:00 come off the contract rate.
Retryable error classes are tunable tenant-wide, auth failures on named domains get carve-outs, and automatic shutoff behaviour is a policy you set, not a surprise you discover.
Which failures retry and which stop is not a policy you set on Make; it is fixed to three error classes, and everything past them is wiring you place module by module. Their documentation: "Make automatically retries incomplete executions that have been created because of: RateLimitError, ConnectionError, ModuleTimeoutError" on a published fixed backoff schedule running from 1 minute to 3 hours, and "Other error type usually require changes in the incomplete execution and manual resolving. Make doesn't retry these error types automatically by default." Beyond those three classes, retry versus stop is a per-module error-handler route (a Break handler, default 3 attempts at 15-minute delays, customizable) built into each scenario's blueprint, one placement at a time. Their docs also cap the machinery itself: "For each scenario, there is a limit of 3 incomplete execution retries running in parallel." On the agent surface, alert and retry control is narrower still: documented REST endpoints toggle notification types on and off per team, and no endpoint sets a threshold, digest, destination route, suppression window, or retryable-error list (verified against their API reference, CLI reference, and skills repository, 2026-08-26). An agent that decides a new error type is transient has no list to add it to; a person edits handlers into each affected scenario.
Catch a silent backlog before the customer calls: work that arrived but never ran has its own screen. Elsewhere, queues cap at 10,000 items, and excess webhook data is rejected
Open the scenarioSilent backlogs: everything looks healthy, and nothing is moving.
At 08:10 the dispatcher finds 430 missed-pickup webhooks arrived overnight and never moved past the door. Every status board was green, and the trucks left the yard without the reroutes.
The queue of arrived-but-unprocessed events is a first-class view. "Received but stuck" is visible before a customer notices the gap.
Make's queue visibility is genuinely good and we say so plainly: "Each webhook has its own queue. Go to the Webhooks section in the left menu to view all webhooks and their queues ... switch to the Queue tab ... You will see the parsed items." Arrived-but-unprocessed events are a screen, not an archaeology project. The cost is what happens when the queue fills. Their documentation: "For every 10,000 credits licensed per month, you can have up to 667 items in each webhook's queue. The maximum number is 10,000 items in the webhook's queue. When the webhook queue is full, Make rejects all incoming webhook data which is over the limit." So during exactly the incident this row exists for, a downstream outage backing events up, the backlog has a hard ceiling of 10,000 items per queue, and the event past it is not waiting for you in a tab. Per their own words it is rejected at the door, which is the one kind of unprocessed event no queue view can show you.
Type a customer's email or order number and land on the runs that touched it across every account. An hour of log reading becomes a minute. Elsewhere, full-text search is per scenario on Pro and up; cross-account search is manual
Open the scenarioCorrelating a failure across accounts meant reading logs by hand.
Claim AV-2291884 was acknowledged to the policyholder but never reached the loss adjuster, and the regulator's clock runs out Monday. Nobody knows which of 74 broker accounts it passed through.
Search every account at once for a value, a client ID, an email, an order number, and land on the runs that touched it. Correlation is a query, not a shift.
Correlating one payload across your customers on Make means one search per scenario, on the right plan. What exists is real: "Full-text execution log search ... lets you search for any term appearing in module outputs within the scenario execution history." It is invoked from a single scenario's History tab, it is "Available on Pro and higher plans", and "If you upgrade from lower tiers, Fulltext search will only display executions that were run after the upgrade." Make Grid's content search is also real, but it "scans all scenario configurations", the build artifacts, not the run data. Make does not document searching run data across all scenarios, teams, or organizations in one query. We searched help.make.com/scenario-history, the Make Grid documentation, and the Make API's logs endpoints. On that basis, a cross-account search by the data itself is manual work (repeating the per-scenario search, or scripting the logs API scenario by scenario) rather than a platform behaviour. Every search is also bounded by the log window: execution logs are kept 7 days on Free, 30 on Core, Pro and Teams, and 60 on Enterprise, so the searchable universe is at most the last two months on any published plan.
A support question that used to need a database ticket and two days gets answered in the meeting. Elsewhere, beyond the dashboard, analysis is CSV export into your own tools
Open the scenarioDiagnosis stalled waiting for someone with database access.
The overnight sync left 260 students without timetable records, and a queue is forming at the registry counter on day two of term. The registrar has a theory she cannot test without database access.
"Is it only annual-plan members? Only one region?" gets answered in seconds with a guardrailed read-only query, by the person, or the AI, doing the diagnosis.
When the question about your own data is one the dashboard was not built to answer, the documented route on Make leads out of Make. What exists: "Export Scenario history ... as a CSV file for a deeper analysis", and an "Analytics Dashboard: Get insight into how workflows are utilized and perform over time" in the pricing feature table. Make does not document an ad-hoc query interface over execution data. We searched help.make.com/scenario-history, the pricing feature table, and the Make Grid documentation. On that basis, answering a question the dashboard does not pre-compute is manual work (CSV export into your own tooling) rather than a platform behaviour. The export is also bounded by what the history still holds: execution logs run 7 to 60 days by plan, so the dataset you can pull into that spreadsheet is at most the last two months.
When the finger-pointing starts, who changed what and when is a query. Elsewhere, audit logs are Enterprise-only and kept for 12 months
Open the scenario"Who changed this, and when" had no answer.
The onboarding integration spent four weeks writing the wrong branch code onto new accounts. Tuesday's audit asks who changed that mapping, and when. Two contractors and one internal team had access.
Every material change, who, what, when, is queryable per account when the finger-pointing starts, or before it does.
Who changed a scenario, and when, has an answer on Make, on one plan. Their documentation: "Audit logs allow you to monitor user activity within your organization or team ... audit logs can help you identify who updated the scenario and when it happened." And the gate, in their own words: "Audit logs are available on the Enterprise plan only. Organization owners and admins as well as team admins can access audit logs." and "Audit logs are stored for 12 months." (https://help.make.com/audit-logs, seen 2026-08-26). For completeness, a narrower record exists on all plans: each scenario's history carries a change log of "Scenario scheduling changes, Scenario edits, Scenario activation." That answers what changed on one scenario; the who-did-what-across-the-account record is the Enterprise audit log, with its 12-month window.
Support sees what the customer sees and fixes it there, without ever asking for a password. Elsewhere, no documented support impersonation; access is an invite the customer grants and revokes
Open the scenarioSupport asking customers for passwords is both a security problem and a delay.
Recall reminders stopped Friday and a practice manager has 90 patients unconfirmed for this week's chairs. The playbook is her login, which your security policy forbids, or two days for an engineer.
Support switches into the customer's account context with its own audited access, sees what the customer sees, and never asks for a password.
Support access without passwords is not something Make's documentation describes for standard plans. The nearest documented flow is credential requests, which solves a different problem, collecting a customer's credentials at onboarding: "Recipients can use this link to join your Make organization with a Guest role, with permissions limited to providing and managing the requested connection credentials." It is gated, "available to official Make Partners and Enterprise customers upon request", and it moves the customer into your Make organization rather than your support engineer into theirs. Make does not document a support impersonation or switch-account mechanism. We searched the help.make.com organizations and teams pages, the White Label documentation's role and administration pages, and the help center's Developers section. On that basis, working inside a customer's account is manual work (an invitation the customer administers, granting your support user a role in their organization or team) rather than a platform behaviour. That shape has a day-two cost: every support session begins with the customer doing something, and ends with someone remembering to revoke what was granted.
Support stops being the silent tax on your margin. The question every vendor dreads, "what happened for this one customer three weeks ago," has a fixed cost of minutes, answered by one person, with the evidence still there.
White Label is a real OEM product and its custom-domain coverage is unusually broad: public and admin interfaces, OAuth redirects, webhooks, mailhooks and outbound email. What their own docs say survives it is the whole argument: "A Base domain exists for all instances", it "Always has our branding", and the custom domain is configured by Make's infrastructure team through a CSM process. The embeddable route, Bridge, returned HTTP 404 on re-check on 2026-08-26, and MCP tools live on Make's hosts, with scenario-run calls capped at 25 seconds on mcp.make.com and 40 seconds on the zone MCP token URL.
Your customer never sees the engine. They see a setup screen, a connect button, a status page, and increasingly, a tool their own AI can call. Whether those surfaces feel like your product or like someone else's is a brand decision you are making when you pick the platform.
Customers set up the integration inside your product, on your domain, with no second settings screen to build. Elsewhere, the embed component's docs return 404 (re-verified 2026-08-26); the documented route is a Make-implemented White Label instance
Open the scenarioCustomers were being sent to a third-party integration UI that broke the product experience and advertised the vendor's supplier.
The settings that drive the integration are the interface the customer configures it with. No translation layer, no second UI to build and keep in sync. Your customers never see the platform. They think it is you.
Lumen, a veterinary-practice SaaS, is shipping a bookkeeping integration inside their product. The bar: a practice manager clicks "Connect accounting" in Lumen's settings, authorizes, maps two fields, done, without ever leaving Lumen, seeing another company's name, or touching a URL that is not lumen-branded. Because the practice manager is not buying an integration platform. She is trusting Lumen.
The customer's takeaway: "Lumen's integrations are great." Which is the entire point.
Putting setup screens inside your product is the row where Make's own story changed under our feet: the component built for it is delisted. Make Bridge, the embedded wizard whose archived examples repo promised 'End users can configure and activate automation scenarios without logging into Make', had no resolving public documentation when we checked: developers.make.com/bridge-documentation returned HTTP 404, and www.make.com/en/bridge served generic Make content with zero Bridge mentions (seen 2026-08-25, re-verified 2026-08-26), while make.com's own llms.txt still lists 'Make Bridge: Pre-built Integrations'. That is dated URL evidence, not a discontinuation notice; availability is a question for Make sales.
What their documentation does describe is Make White Label, and it is a real OEM product: a rebranded Make instance 'implemented by Make', with public and admin interfaces on your custom domain, OAuth redirects, webhooks, mailhooks and outbound email on your domain, and end-user lifecycle provisioning by admin API. But what it embeds is Make's builder, not screens of your product: 'A customer is an organization' whose people work in the platform's scenario workspace, wearing your logo.
On the plans on the pricing page, the setup surface is Make itself. The documented way a customer hands you a connection is a credential-request link, and 'Recipients can use this link to join your Make organization with a Guest role': your customer gets an account role in the vendor's system, in the vendor's UI.
Your customers' AI assistants can drive multi-system work through your product, with an approval gate before anything destructive and a record afterwards. Your domain, every tier. Elsewhere, tools live on Make's hosts, capped at 25 seconds on mcp.make.com and 40 seconds on the zone MCP token URL
Open the scenarioCustomers now want their own AI agents to reach these systems, and hand-building an interface per client does not scale.
An operations director at one of your customers types into her AI assistant: "Move every Thursday booking at the Riverside location to Friday and notify the affected members." For that sentence to become action, her AI needs a tool: a governed, authenticated, rate-limited operation that does the multi-system work and reports back. Your customers will judge your product on whether their AI can drive it.
The Thursday bookings move, the members get notified, and the audit trail shows exactly what her agent did.
Make ships this, and the trade sits in whose hostname the AI calls and how long a tool may take. The MCP server 'turns your active and on-demand scenarios into callable tools for AI', and MCP toolboxes are 'dedicated Make MCP servers that connect AI systems, such as Claude and ChatGPT, to specific sets of scenarios used as tools', with configurable labels, Read only and Read & write types, and multiple shareable keys per toolbox. That is a real, current capability, and this row concedes it.
The endpoints those AIs call are Make's: the MCP server is https://mcp.make.com, and a toolbox generates its URL on your Make zone host, the worked example on their page reading https://eu2.make.com/mcp/server/... , so on the plans in the pricing table the tool your customer's AI lists carries a Make hostname rather than yours. Each tool must be a scenario set active with on-demand scheduling and defined inputs and outputs, and the calls run under published response ceilings: per their MCP documentation, scenario-run tool calls time out at 25 seconds on https://mcp.make.com with OAuth and at 40 seconds on the https://<MAKE_ZONE>/mcp/<TRANSPORT> MCP token URL, after which the scenario keeps running (up to the 40-minute execution cap) and the client is left polling executions_get for the result. Work that fits inside a 25 or 40 second window returns as an answer; anything longer returns as a poll.
The AI assembles the setup screen, so there is no front-end project: validated input, live choices from the customer's systems, embed code returned. Elsewhere, run forms render inside Make; no embeddable end-user form builder is documented
Open the scenarioConfiguration UIs were bespoke front-end projects, every time.
Palletworks promised its three largest brokers a screen that pulls their live carrier list and validates SCAC codes before anything saves. Its two front-end engineers are nine weeks into a backlog.
Customer-facing forms assemble from a catalog of elements and saved patterns, validate input, refresh their choices from the customer's live data, and drop into any page with an embed code.
Configuration forms for your customers stay a bespoke front-end project on your side of the fence. What Make documents is scenario inputs, a run form that renders inside Make: 'Scenario inputs: Run complex scenarios simply by filling in inputs that are marked as required' (pricing page). Live data choices exist too, as RPCs that 'retrieve live data from a service for an input field', but their docs scope them to the builder: 'These requests are invoked while the user interacts with the modules when building a scenario.' An embeddable form builder your end customers use, with validation and live data dropdowns, is a different thing, and Make does not document one. We searched the pricing feature table, help.make.com's scenario inputs and outputs pages, and the White Label customization docs, whose rebranding list is 'Instance name, Logos, Favicon, Color theme, Help center and support links, Language settings', not end-user form building; the component that once carried this, Make Bridge, has no resolving documentation (404, re-verified 2026-08-26). On that basis it is manual front-end work rather than a platform behaviour.
A new customer connects, maps and goes live without anyone from your team on the call. Elsewhere, partner or Enterprise gate, and the customer joins your Make organization as a Guest
Open the scenarioEvery new customer connection required a human on both sides.
310 schools want the gradebook-to-parent-messaging connection live in three weeks. Each takes a 40-minute screenshare with a Coursefold engineer: 206 hours of calls, four people in implementation.
The customer clicks connect, authorizes, maps what needs mapping, and is running, inside your product, with nobody from your team on the call.
Self-serve connection exists here, with a gate in front of it and Make's premises behind it. Credential requests are the documented route: 'You can now use credential requests to securely collect connection credentials from third parties ... Recipients can authorize connections in minutes.' Sending them is not on every plan's table: 'This feature is available to official Make Partners and Enterprise customers upon request. To enable it, each user needs to submit a form.' The customer also does not stay inside your product: 'Recipients can use this link to join your Make organization with a Guest role, with permissions limited to providing and managing the requested connection credentials.' To hand you one credential, your customer joins the vendor's organization, in the vendor's UI, on the vendor's domain. The connection is self-serve; the surface it happens on is Make's.
The assistant you ship resolves requests instead of deflecting them: real lookups, real writes, an approval gate before anything destructive, full logs. Elsewhere, an open-beta scenario module, scoped by Make's own guidance to intern-level tasks
Open the scenarioA chatbot that cannot act is a deflection tool, not an integration.
Aldergate's chat agent handled 6,400 conversations and 2,100 ended as after-hours callbacks. A tenant asks at 11pm to move Thursday's plumbing visit, and all the agent can offer is an on-call number.
Agents you ship to customers carry explicit goals and scoped tools, and act through the same governed execution engine as everything else: real lookups, real writes, approval gates, full logging.
The acting chat agent exists, in beta, sized by Make's own advice. Make AI Agent (New) is 'an AI system that independently performs tasks for you based on your instructions', and its tools 'are modules, scenarios, MCP server tools, and other agents'; it is in open beta, 'available on all plans using Make's AI Provider, with the option to use custom AI provider connections on paid plans'. That is an agent that does work, not a deflection bot, and the row concedes it. Their help page then sets the operating envelope in their own words: 'choose tasks for your agent that you trust an intern to handle. Avoid tasks involving sensitive data, high-stakes financial or strategic decisions, or strict legal requirements.' And the agent is a module inside Make scenarios, not a surface in your product: the White Label docs enumerate rebranding of Make's own interface, no documented route builds end-user-facing screens of your product, and the embeddable component (Bridge) has no resolving documentation as of 2026-08-26. Putting this agent in front of your customers means building the chat surface yourself and running it into Make's beta runtime.
Every surface a customer's IT team inspects, screens, addresses, callbacks, carries your name on every plan. Elsewhere, a Make-branded Base domain exists on every instance; the custom domain goes through Make's CSM process
Open the scenarioAn integration layer that shows a supplier's name tells your customer who really built it.
Fenmark is 48 hours from signing a carrier worth 1.4 million a year. Question 41 asks for every hostname claim data touches, and its webhook receiver answers on a domain carrying someone else's name.
Every surface a customer or their IT team can inspect, the UI, the webhook URLs, the authorization callbacks, carries your name, at every tier.
Under White Label the domain coverage is broad, and the row credits it before arguing: their docs put 'public and admin interfaces ... available on your custom domain', 'Emails from the custom domain to your end customers', 'OAuth redirects with the custom domain', and 'API calls, webhooks, and mailhooks using any configured domain', with the in-product support links and support email pointing at you. That list is stronger than most vendors publish. Two of their own sentences keep every surface from being yours alone. 'A Base domain exists for all instances and has the URL {{customName}}.onmake.com or {{customName}}.make.celonis.com or similar. Your Base domain: Always has our branding.' And each OAuth app binds to a single domain: 'You can use either your Base or Primary domain as the redirect URI but not both.' A hostname questionnaire answered from their documentation always contains a Make-branded entry. Getting there is a Make process rather than a setting: the instance is 'implemented by Make', the Primary domain is 'the custom domain that you configure with Make's assistance', and 'Existing customers can contact their CSM with their desired custom domain to start the process.' On the plans on the pricing page, nothing runs on your domain: app, API and OAuth on eu1 through us2.make.com, the MCP endpoints on mcp.make.com.
The integration experience compounds into your brand instead of your supplier's. Every setup flow, every status page, every AI tool call is a moment your product looks finished, in your customer's language, on your domain.
Concede the build side without hedging: Maia builds, edits and debugs the run in front of you, one-click AI error explanations shipped in July 2026 with no plan gate stated in the release note, toolboxes scope which tools a client sees, and Make Skills are documentation the AI reads before it acts, so three rows here are deleted. The published bound is day two: "She can't view execution logs from past scenario runs ... You must explain the error to her yourself", and "She can't view other scenarios" (updated 12 Aug 2026).
Everything on this page is exposed to AI, but "AI-powered" is the emptiest phrase in the category. The question with teeth: which phases of the integration lifecycle does the AI have real tooling for? Building is one phase. There are seven more.
One person and the AI cover an integration's whole life, launch through incidents. Elsewhere the AI diagnoses, then a developer does the fixing. Elsewhere, runbooks end at build; day two is self-scripted REST
Open the scenarioAn AI with raw API access improvises. An AI with encoded procedures repeats what works.
Day two. The integration is built and live; both platforms' AI tooling got you here, and both did it well. Now the real career of an integration begins: a customer reports a discrepancy, an API starts rate-limiting, an alert needs tuning, a fix needs to reach the fleet. The question for the AI is no longer "can you build it." It is "how much of what happens next can you handle?"
One person and the AI cover the lifecycle. Day two looks like day one.
What this costs you: the AI that helps you build is not the AI that runs the operation. Day one is well covered; day two is whatever your team scripts against the raw API.
The day-one side is real and belongs in the open. In-product, Maia "creates scenarios, modifies existing ones, and fixes errors for you using your prompts", and since July 2026 any plan can click a module's error bubble and "Explain error, to see an AI-generated explanation of what happened and possible fixes". For outside assistants, Make publishes genuine runbooks: Make Skills are "markdown files (.md) with reference information, best practices, and instructions on Make-specific topics". The skills repo at v0.1.7 ships five of them (the help page lists four): scenario building, module configuring, MCP referencing, API shell workflow, and E2B code execution. Every one is build and configure phase.
The runbooks stop where the lifecycle keeps going. Reading the full tool inventory of Make's shipped SDK (2026-08-26), no packaged agent tool names stop, retry, or replay; the incomplete-executions category ships exactly two tools, list and get, both flagged readOnlyHint: true in the source. Those production verbs exist, but as raw REST endpoints ("Stops a running execution. Use force: true to immediately terminate the execution") that no skill, MCP tool, or CLI command encodes as a procedure. And Maia's own page, updated 12 Aug 2026, lists her limits: she "can't view execution logs from past scenario runs, so she's unable to analyze previous errors. You must explain the error to her yourself", and she "can't view other scenarios"; she can see the log of the run you trigger with Run once.
The AI files the platform defect it hits, so it gets fixed instead of papered over by an undocumented workaround. Elsewhere, bug reports stay a human support ticket
Open the scenarioAgents silently working around platform bugs means the bugs never get fixed.
The platform layer behaves differently than documented, the AI routes around it, and that detour is permanent, undocumented, and a 2am problem next hail season. The supervisor has inherited three.
When the AI hits a platform-layer defect, it files a structured report to engineering, autonomously, instead of quietly routing around it. The tools get better because the agent using them is also their reviewer.
Make does not document this. We searched skills.make.com, help.make.com/make-skills, the developers.make.com MCP server tool descriptions, the full Make CLI reference (its command groups are Scenarios, Credentials, Data stores, Account management, and Custom app development, with no feedback or report command), and the Maia documentation, most recently on 2026-08-26. On that basis it is manual work rather than a platform behaviour: when an agent hits a Make platform bug, reporting it remains a support ticket a person files at make.com/en/ticket. The nearest published surface runs in the other direction. Every developers.make.com page answers an agent's questions ("GET <url>.md?ask=<question>"), which is a read channel; nothing on the MCP server, the CLI, or the skills files a report back to Make.
The AI is not a build accelerator bolted to the front of the lifecycle. It is a colleague with a runbook for all of it, which is why one person can run what used to take a team.
Every row on this page reduced to the same fork. On APIANT, the job was a walkthrough: find it, see it, change one node, prove it, ship it everywhere. On Make, the same outcome was reachable, usually, and it was a project: a code artifact to edit, a pattern to hand-build, a script to write against their API, a window that had already closed. Not because their team built a careless product. They built a serious one. But their platform is made of code at the layer that matters, and their AI's output is code, so every question on this page eventually hit the same wall: the thing that runs your business is an artifact only developers can safely touch, and the AI that builds it cannot fully operate it afterwards. On APIANT the integration is a structured document at every layer, which is why the AI can build it, a compiler can refuse the invalid version of it, a test can force every branch of it, a person can read it, and one command can ship it to a fleet. That is not forty-nine features. It is one architecture, showing up forty-nine ways.
Then you write code, in the one place code belongs: a scripting escape hatch that slots in as a single node of the structured document. Code is an optional leaf inside a data document, never the foundation. The loop, the branches, the mappings, the tests around that leaf all remain visible, machine-editable, and compiler-checked; the custom logic is contained to the one spot that genuinely needed it.
Compare the shape of the same answer elsewhere: when the model runs out, the escape hatch is more code on a foundation that is already code. The exception and the rule are indistinguishable. Here, the exception stays the exception, and a decade of production has kept it rare.
Own the outcome, and be precise about what owning the artifact costs. A code integration is cheap on day one and priced like a liability thereafter: it is reviewed by whoever has time, it carries a dependency tree that ages, every API drift re-opens it, and its real documentation is the memory of whoever wrote it. Multiply by every integration you will ever ship, then by the years you will run them, then subtract the engineers who will have moved on. That is the asset you would own.
What you own on APIANT is the thing you actually wanted: integrations that run, on your domain, inspectable by your team, provable before they ship, and operable by AI for as long as you run them. The buildings your company works in are owned this way too: you own the use of something built and maintained by people whose whole business is that it never falls down.
The API with no catalog entry, the forty custom fields, the sync that loops, the customer report from three weeks ago. One working session, on your systems, and you watch it built, tested on every branch, and running. Judge the architecture with your own scenario, which is what this page has been asking you to do all along.
Book a working session See the AI operate the platformScenario companies on this page are composite illustrations drawn from real deployment shapes. Company names are fictional and are not customer references. Where a figure comes from a live APIANT deployment it is identified as such and the customer is not named. Every statement about Make on this page derives from Make's public documentation, public repositories, blog, and pricing page as reviewed in August 2026. Direct quotes are reproduced verbatim for comparison purposes. Make is a trademark of Make; all product names belong to their owners. Platform capabilities evolve; verify anything decision-critical against the current versions of the linked pages.
