Make

Make (Integromat) — operate scenarios by REST API and MCP

Drive a live Make.com account from code or an agent: create scenarios from a blueprint, activate/run/stop/clone/delete them, and manage the connections, hooks, data stores, and teams around them. This skill owns the operate half — the API v2 calls and the MCP wiring. It does not design the flow; what a scenario should do (trigger, routes, mapping, dedup, error handler) lives in automation-flows, and the Make-vs-n8n-vs-Zapier billing call lives in automation-strategy. Bring the design here, and this skill turns it into API payloads and MCP tool calls.

Reality up top (verify at author time — Make ships fast):

• REST API v2 is GA. Base URL is zoned: https://{zone}.make.com/api/v2.
• The Make MCP server is GA and free on every plan — you only pay the scenario credits a run consumes. Cloud MCP has two tool tiers: run tools (all plans) and management tools (paid).

Connect first — API token vs MCP

Two ways in, chosen by who is driving:

• REST API v2 — deterministic CRUD from your own scripts/CI. Full control of the blueprint. Use for provisioning, bulk edits, activate/stop pipelines.
• Make MCP server — lets an MCP client (Claude, Cursor, ChatGPT) call your scenarios and (on paid plans) manage them as tools, no glue code. Use when an agent is the operator.

.env (never inline secrets — read from the environment):

MAKE_ZONE=eu2.make.com        # your org's zone — eu1|eu2|us1|us2 (+ celonis). WRONG ZONE = AUTH ERROR.
MAKE_API_TOKEN=xxxxxxxx        # Profile → API/SDK → API token. Scopes are FIXED at creation.
MAKE_TEAM_ID=123456            # teamId a scenario is created under (integer)
MAKE_MCP_TOKEN=yyyyyyyy        # separate MCP token, for the token-URL MCP transport

Auth header (API): Authorization: Token {MAKE_API_TOKEN} — the literal word Token, a space, then the token. OAuth2 is the alternative for multi-user apps. Scopes are chosen when the token is minted and cannot be widened later — mint with scenarios:read scenarios:write (and connections, hooks, datastores, teams as needed) up front; a too-narrow token means re-minting, not patching.

The scenario model (just enough to build the payload)

A scenario = exactly one trigger module, then a chain of action modules, optionally split by routers into branches. Data flows by mapping: a downstream field references an upstream output as {{2.email}} (module 2's email). The whole thing serializes to a blueprint — the JSON you GET, edit, and POST back. That is the entire operate-side model you need here.

Do not design the flow in this skill. Trigger choice (webhook vs polling), branch logic, idempotency/dedup on a data store, and the error handler (Break → Incomplete Executions, etc.) are all automation-flows. Take its build sheet, then encode it as a blueprint below.

API v2 surface

Two rules that bite: endpoints and query keys are case-sensitive, and every call is zoned — the same token against the wrong {zone} returns an auth error, not a 404, which sends people chasing a token problem that does not exist.

Rate limits are per plan (req/min): Core 60 · Pro 120 · Teams 240 · Enterprise 1000. Read your own real ceiling rather than guessing:

curl -s -H "Authorization: Token $MAKE_API_TOKEN" \
  "https://$MAKE_ZONE/api/v2/organizations/$ORG_ID" | jq '.organization.license.apiLimit'

Dynamic lifecycle — the blueprint round-trip

The core technique: you rarely hand-write a blueprint. You GET one from a template or an existing scenario, mutate the JSON, and POST/PATCH it back as a string. blueprint and scheduling are sent as JSON strings, not objects.

1. Get a starting blueprint

# From an existing scenario (or a template: GET /templates/{id}/blueprint)
curl -s -H "Authorization: Token $MAKE_API_TOKEN" \
  "https://$MAKE_ZONE/api/v2/scenarios/$TEMPLATE_ID/blueprint" \
  | jq '.response.blueprint' > bp.json   # wrapper key: verify .response.blueprint at author time

Mutate bp.json with your design — module parameters, the {{n.field}} mappings, router filters. Keep secrets out; wire credentials via a connection id, never a literal key in the blueprint.

2. Create the scenario (blueprint + scheduling as STRINGS)

curl -s -X POST -H "Authorization: Token $MAKE_API_TOKEN" \
  -H "Content-Type: application/json" \
  "https://$MAKE_ZONE/api/v2/scenarios" \
  -d "$(jq -n --argjson team "$MAKE_TEAM_ID" \
        --arg bp "$(jq -c . bp.json)" \
        --arg sched '{"type":"on-demand"}' \
        '{teamId:$team, blueprint:$bp, scheduling:$sched}')"
# scheduling e.g. {"type":"indefinitely","interval":900} (interval seconds) — verify fields at author time.
# optional: folderId, basedon (template id)

3. Validate

The create call itself is the validator — a malformed blueprint returns a 400 naming the offending module/field. Fix the JSON and re-POST. There is no separate schema-lint endpoint; a clean create is the pass.

4. Dry-run / test before you schedule

Run it once, watching one execution, while still on-demand (inactive):

curl -s -X POST -H "Authorization: Token $MAKE_API_TOKEN" \
  "https://$MAKE_ZONE/api/v2/scenarios/$ID/run" \
  -H "Content-Type: application/json" -d '{"responsive":true}'
# inspect the returned execution/bundle output before trusting the flow

5. Activate

# switch scheduling off on-demand first (PATCH), then start
curl -s -X POST -H "Authorization: Token $MAKE_API_TOKEN" \
  "https://$MAKE_ZONE/api/v2/scenarios/$ID/start"

6. Manage — patch, stop, clone

# Update: same round-trip — GET blueprint, mutate, PATCH back as a string
curl -s -X PATCH -H "Authorization: Token $MAKE_API_TOKEN" \
  -H "Content-Type: application/json" \
  "https://$MAKE_ZONE/api/v2/scenarios/$ID" \
  -d "$(jq -n --arg bp "$(jq -c . bp.json)" '{blueprint:$bp}')"

curl -s -X POST -H "Authorization: Token $MAKE_API_TOKEN" ".../scenarios/$ID/stop"
curl -s -X POST -H "Authorization: Token $MAKE_API_TOKEN" \
  -H "Content-Type: application/json" ".../scenarios/$ID/clone" \
  -d '{"teamId": 999, "name": "copy"}'   # clone into another team

7. Delete — export first (irreversible)

DELETE /scenarios/{id} is permanent; there is no undo and no trash. Never delete a live scenario without exporting its blueprint first.

curl -s -H "Authorization: Token $MAKE_API_TOKEN" \
  ".../scenarios/$ID/blueprint" | jq '.response.blueprint' > backup-$ID.json  # export
curl -s -X DELETE -H "Authorization: Token $MAKE_API_TOKEN" ".../scenarios/$ID"