Make vs Latenode at a glance

Why teams migrate: the per-operation billing problem

Make counts an operation every time a module executes. A four-module scenario run once uses four operations. Run it a thousand times and that’s four thousand.

As of August 2025, Make bills this usage in credits rather than raw operations, but the underlying count is unchanged — one operation still converts to roughly one credit, so the loop-heavy scenarios that used to burn operations now burn credits at the same rate.

The real cost shows up once loops enter the picture: an Iterator processing fifty records, followed by a Router and an Array Aggregator, can multiply the operation count for a single trigger event many times over. A ten-module scenario doesn’t just cost more than a four-module one — it costs proportionally more every single run.

Latenode’s model changes what you’re paying for. Instead of counting steps, it meters compute time. A loop over the same fifty records inside one JavaScript node runs as part of a single execution — the cost scales with how long the code takes to run, not with how many items or modules were involved.

That’s the entire argument for migrating scenarios with loops, iterators, or several sequential AI calls: the same logic, priced differently.

Setting up your first Latenode webhook trigger

Every migrated scenario starts the same way a Make scenario does: with a trigger. For anything driven by an external event — a form submission, a Stripe payment, a CRM update — that trigger is a webhook.

Step by step

• Create a new scenario in the Latenode workspace.
• Add a Trigger on Webhook node as the first node. This is the entry point — nothing runs until a request hits its URL. Latenode’s official Trigger on Webhook documentation covers the node’s full configuration options if you need something beyond the basics below.
• Note the two generated URLs. The Development URL runs the scenario once per request and stops, which is what you want while testing. The Production URL runs continuously and is what goes into the live integration.
• Send a test request to the Development URL from the external service, or with a tool like Postman, and confirm the payload shape in the execution log before building anything downstream.
• Choose GET or POST depending on whether the trigger needs to carry data (POST) or is a simple ping (GET).
• Switch to the Production URL in the external service’s webhook settings only once the scenario has been fully built and tested end to end.

The JavaScript node: replacing multi-module Make chains

This is the node that does the actual replacing. It runs in a cloud sandbox for up to three minutes per execution, supports standard NPM packages, and receives data from the previous node as ordinary variables — no special expression syntax required.

The clearest example is parallel HTTP requests. In Make, an HTTP module fires one request at a time; looping it over a list of records with an Iterator means paying for each request as a separate operation, sequentially.

A JavaScript node using a library like Axios can fire all of those requests in parallel with Promise.all inside a single execution — one billed run instead of one operation per record.

const axios = require('axios');

// data.records comes from the previous node (e.g. the webhook payload)
const records = data.records;

// Fire every enrichment request in parallel instead of one at a time
const results = await Promise.all(
  records.map(async (record) => {
    const response = await axios.get(`https://api.example.com/lookup/${record.id}`);
    return { ...record, enriched: response.data };
  })
);

return { results };

What used to be a Webhook module, an Iterator, an HTTP module inside the loop, and an Array Aggregator to recombine the results — four Make modules, each billed per pass through the loop — becomes one JavaScript node billed for its total runtime.

Latenode’s built-in AI Copilot can also generate this kind of code from a plain-language description, so writing raw JavaScript from scratch isn’t a requirement for migrating logic like this.

Mapping Make modules to Latenode nodes

Most migrations go module by module. Use this as a starting translation table, then collapse anything that’s purely data-shaping into a single JavaScript node where it makes sense.

Step-by-step Latenode Make.com migration guide: moving an existing scenario

• List every module in the live scenario and note what each one does, in order. This becomes your build checklist.
• Rebuild the trigger first. If it’s a webhook, create the Trigger on Webhook node and confirm the Development URL receives the same payload shape as the Make webhook currently does.
• Rebuild native integrations with native nodes where Latenode has a direct equivalent (CRM actions, Slack messages, spreadsheet writes) rather than routing everything through JavaScript.
• Collapse loop-and-transform logic into one JavaScript node using the mapping table above — this is usually where the operation savings come from.
• Run the new scenario against real (or replayed) payloads using the Development URL, and compare its output field-by-field against what the live Make scenario produces.
• Cut over the integration — update the external service’s webhook setting to the Latenode Production URL — only after outputs match.
• Leave the Make scenario paused, not deleted, for at least one full billing cycle in case an edge case surfaces that testing missed.

Common migration pitfalls

The recommended setup

If a scenario is short, low-volume, and maintained by someone who doesn’t want to touch code, there’s no pressing reason to move it. Make’s polish and documentation are still genuinely better for that case.

For anything where an Iterator, Router, and Aggregator are doing the real work, migrating that logic into a Latenode JavaScript node is where the cost argument holds up. The same goes for scenarios chaining several AI calls or firing parallel API requests. Keep native nodes for the simple integration steps either way.

Frequently asked questions