Skip to content
Guide intermediate

Make Ships CLI, API v2, and a Module Migrator in One April Release Window

The short version

Make's mid-April 2026 release adds a terminal CLI, a v2 API with per-scenario usage tracking, and a Module Migrator. The CLI is the one that changes who should pick Make.

Published May 1, 2026 by Pondero Editorial
Table of Contents

Make Ships CLI, API v2, and a Module Migrator in One April Release Window

Three things landed between April 15 and 17, 2026: the Module Migrator (April 15), then API v2 and the generally-available Make CLI (both April 17). Two of them are quality-of-life. The CLI is the one that matters, because it is the first first-party command-line tool from any of the big three hosted automation platforms, and it removes the single argument that has sent engineering-led teams to n8n for two years: you could not put a Make scenario under version control and gate its deploy on a code review.

The CLI is the load-bearing change

Until April 17, the only way to edit, deploy, or inspect a scenario was the visual builder logged into a browser session. Scenario definitions lived inside Make's database with no exportable, diffable artifact a CI system could act on. That is why "we can't code-review our automations" was a real objection, and why technical teams who wanted PR-gated changes self-hosted n8n instead.

The CLI changes the artifact, not just the access path. You authenticate with a Make API token, then pull a scenario's blueprint as JSON, commit it, and push it back:

# Authenticate once with a Make API token
make auth login --token <YOUR_MAKE_API_TOKEN>

# Pull a scenario blueprint to a versionable file
make scenario export --id 482193 > scenarios/lead-router.blueprint.json

# After review + merge, push it back
make scenario import --id 482193 --file scenarios/lead-router.blueprint.json

That is the whole CI story in three commands: a git-tracked blueprint, a diff a reviewer can read, an import gated behind a merged PR. The same auth model covers make scenario run for on-demand triggering and make scenario logs for pulling execution history into a pipeline health check. None of this is exotic. It is the baseline wrangler/vercel-shaped workflow developers already expect, arriving two years late but arriving first among hosted competitors.

API v2: the useful part is the bill

API v1 still works and is not deprecated. v2 ships credential requests and new connection filters, but the line item that earns the upgrade is extended usage tracking: per-scenario operation counts instead of one aggregate org number. Finance and ops teams have been reverse-engineering which scenarios burn the operations budget from indirect signals. v2 exposes it directly, which turns "the bill went up, find out why" from a half-day investigation into an API call. Point integrations at v2 only if you need that or the credential-request flow; there is no forced migration.

The Module Migrator solves a smaller, real problem

Make deprecates app modules whenever a vendor changes an auth flow or endpoint shape. Pre-April 15, clearing a deprecation meant opening every affected scenario, finding the step, and rebuilding it by hand. The Migrator scans the workspace, auto-swaps modules where the replacement is a drop-in, and hands back a triage list of the ones that need a human. It does not fix the hard cases; it removes the hunting. On an estate of 50-plus scenarios that is the difference between a quarterly half-day of deprecation archaeology and a triage queue of genuinely broken flows. Run the workspace scan, review the auto-upgrade list before applying it, and work the manual list production-critical first.

Who should act, and who should not

If you already run Make as production infrastructure, wire the CLI into CI this quarter: export blueprints, commit them, gate imports on review. That is the single highest-value move in this release and it closes the developer-experience gap that justified self-hosting n8n on governance grounds alone. If you build in the visual editor and never open a terminal, the CLI is not for you yet, and that is fine. The Module Migrator helps you today regardless of how you build.

The recommendation flips on one condition. If your team self-hosts n8n specifically for data residency or private-network reasons, the Make CLI does not address either; it is a workflow-ergonomics fix, not a hosting-model change. Residency-driven teams stay where they are. Teams that went to n8n only because Make could not be code-reviewed now have a reason to re-run that decision. Pricing is unchanged and all three features ship across existing plans, with the standard rate limits applying to v2 calls.

This post is part of Pondero's daily coverage of AI tool updates. See all guides