Make.com Scenario Backup & GitOps - Blueprints

Back up every Make.com scenario blueprint on a schedule, and keep the version history Make throws away. Make keeps 60 days of blueprint versions and then archives them, on every price tier — this keeps them indefinitely, in an Apify store and in your own Git repository. Paste a blueprint to try it with no account connected, or add a read-only Make API token to back up a whole organization.

• Read-only. Ten read-only scopes. The Actor never starts, stops, edits or deletes a scenario.
• One row per resource per run, saying what changed since the last run and which modules moved.
• Eight resource types, not just scenarios: connections, webhooks, data stores, data structures, keys, scenario folders and custom variables.
• Your own Git repository, optional: a commit per run, and no commit at all when nothing changed.

What does Make.com scenario backup do?

Make's own version history is a 60-day window. Open a scenario, choose a previous version, and anything older than 60 days is gone — Make's documentation says so plainly: "Due to the regular archiving process, only the versions that are not older than 60 days can be retrieved." There is no export-everything button, no diff between two versions, and nothing that tells you which of your 200 scenarios somebody edited yesterday.

This Actor reads your Make organization through the API and writes three things. A dataset row per resource per run says what changed — added, modified, unchanged or removed — with a module-level diff for scenarios. A permanent named key-value store holds the full JSON of every resource, plus a dated copy each time the content actually changes, so you can restore a scenario as it was on a given day. And if you supply a repository, a Git commit per run gives you blame, pull requests and diffs over your automation, with credentials stripped.

It is built for the run that finds nothing. An unchanged organization is read with one list call, not one call per scenario, because Make's lastEdit timestamp is exactly the newest blueprint version's creation time — so an unmoved timestamp proves the blueprint has not changed. A second run over an untouched organization fetches zero blueprints. On 500 scenarios that is the difference between 501 requests and one, and it is what keeps a large account inside Make's per-minute API limit.

What does it back up?

Resource	What is stored	Notes
Scenarios	The full blueprint, scheduling, and the list row	Module-level diff; the blueprint's stored name is corrected from the live name, so a restore cannot rename your scenario
Connections	Name, app, type, scope count	Never the credential, and never the account's e-mail address
Custom variables	Name, type, scope, value	Organization and team scope kept apart; the value is stored but never committed to Git
Webhooks	Name, type, configuration	The URL is stored but never committed — it is a bearer credential in URL form
Data stores	Name, size limit, linked data structure	Row counts are excluded, so a store being written to is not reported as edited
Data structures	The full typed field spec	The field list Make's API omits unless you ask for it
Keys	Name, type, team	Make's API never returns key material, so a key is an inventory entry, not a restorable secret
Scenario folders	Name, path, parent	The whole tree, flattened — nested folders included

Make's own system variables (operationsLeft, dataLeft and the rest) are excluded deliberately. They change on their own as your scenarios run, so backing them up would report your variables as edited every single day.

Why use Make.com scenario backup?

• Keeps what Make deletes. Your blueprint history stops being a 60-day window and becomes permanent — and the first run can seed whatever Make still holds, which is a one-off chance.
• Tells you what changed, not just that something did. 2 modules added, 1 modified on the row, and a real diff in Git.
• Nothing to install, and no credential needed to try it. Paste a blueprint exported from the Make designer and press Start.
• Read-only by design. Ten read-only scopes, no write scope requested or accepted, and no e-mail address in any output.
• Credentials stay out of your repository. Variable values and webhook URLs are blanked in Git while staying intact in the store, so a restore still works.
• Runs on Apify's schedule. Daily runs, the API, webhooks on finish, exports to JSON, CSV and Excel, and integrations with Make itself, n8n and Zapier.

How to back up a Make.com account

Try it with nothing connected:

1. Open the Actor and leave the input as it is — a sample scenario blueprint is already filled in.
2. Press Start.
3. Read the Account changes tab. One row, added on the first run and unchanged after that.

Then back up your own account:

1. In Make, go to Profile → API access → Add token and create a token with these read-only scopes: scenarios:read, organizations:read, teams:read, connections:read, datastores:read, hooks:read, keys:read, udts:read, organization-variables:read, team-variables:read. Three of them — scenarios:read, organizations:read, teams:read — are enough for scenarios alone.
2. Paste it into Make API token, and set Make zone to the first part of your Make URL (eu1.make.com is eu1). A token is valid for one zone only.
3. Leave Resources as it is to back up everything, or narrow it.
4. Optional: turn on Seed past versions on the first run to capture the history Make still holds. Do this on the first run — what it can reach shrinks every day.
5. Optional: add a Repository URL, a Git access token and a branch to get a commit per run.
6. Press Start, then schedule it daily.

Input

Field	What it does
Scenario blueprint	Paste one blueprint, or a list, to back up with no account connected. Accepts the designer's Export Blueprint file.
Make zone	The first part of your Make URL. eu1, eu2, us1, us2 and the two Celonis zones.
Make API token	A read-only Make API token. Sent in a header, never stored in a row or a commit.
Organization IDs	Which organization to back up. Empty uses the first one the token can see and names the others in the run summary. One organization per run.
Team IDs	Back up only these teams. Empty includes every team and every private space.
Scenario IDs	Back up only these scenarios. Empty backs up all of them.
Resources	Which of the eight resource types to include.
Backup store name	The named key-value store holding snapshots and history. Use a different name per Make account.
Seed past versions on the first run	Also store the older versions Make still holds, up to 60 days back. Off by default.
Past versions per scenario	How many older versions to store per scenario when seeding.
Repository URL	HTTPS URL of a repository to commit to. Leave empty for no Git sync.
Git access token	A token allowed to push. GitHub: fine-grained with Contents read and write, or classic with repo. GitLab: a project access token with write_repository.
Branch	Branch to commit to. Created by the first run if the repository is empty.
Directory in the repository	Where in the repository to write. / writes to the root.
What to hide from the repository	standard blanks variable values, webhook URLs and editor identities. strict also masks anything in a blueprint that looks like a credential.

Back up one scenario blueprint with no account connected:

{
    "blueprintJson": {
        "name": "Sample - order intake to CRM",
        "flow": [{ "id": 1, "module": "google-sheets:watchRows", "version": 2 }],
        "metadata": { "version": 1 }
    }
}

Back up a whole Make organization every day, and commit it to GitHub:

{
    "makeZone": "eu1",
    "makeApiToken": "<your Make API token>",
    "include": [
        "scenarios",
        "connections",
        "customVariables",
        "dataStores",
        "dataStructures",
        "hooks",
        "keys",
        "scenarioFolders"
    ],
    "gitRemoteUrl": "https://github.com/you/make-backups",
    "gitToken": "<your Git access token>",
    "gitBranch": "main",
    "gitPath": "make/"
}

Output

Every run writes one row per resource to the default dataset, exportable as JSON, CSV or Excel. The full JSON of each resource goes to the named key-value store — the run summary links it — and a summary-run record holds the totals.

The first input above produces this row:

{
    "runAt": "2026-09-24T10:14:04.230Z",
    "zone": "eu1",
    "resourceType": "scenario",
    "resourceId": "pasted-7025f2b88e23",
    "name": "Sample - order intake to CRM",
    "changeType": "added",
    "moduleCount": 6,
    "modulesAdded": 6,
    "modulesRemoved": 0,
    "modulesModified": 0,
    "connectionCount": 2,
    "routeCount": 2,
    "diffSummary": "New scenario with 6 modules",
    "contentHash": "2b28b6c42f90908481569f36980a6dbf137a93edd187f90ac5384dcc756b3c6a",
    "secretsFound": 1,
    "snapshotKey": "scenario-eu1-paste-pasted-7025f2b88e23-latest"
}

The second input produces one row like this per scenario, plus one per connection, variable, webhook, data store, data structure, key and folder:

{
    "runAt": "2026-09-24T09:35:26.598Z",
    "zone": "eu1",
    "organizationId": "8966576",
    "organizationName": "My Organization",
    "teamId": "2764615",
    "teamName": "First team",
    "resourceType": "scenario",
    "resourceId": "7461796",
    "name": "Summarize Google Document",
    "changeType": "added",
    "isActive": false,
    "scheduleType": "indefinitely",
    "scheduleInterval": 900,
    "moduleCount": 3,
    "modulesAdded": 3,
    "diffSummary": "New scenario with 3 modules",
    "contentHash": "eb44d2e35b4e4a38267163cff700b353cfb766993841a7882d7ade629543747e",
    "lastEdit": "2026-09-23T12:33:26.971Z",
    "secretsFound": 0,
    "snapshotKey": "scenario-eu1-8966576-7461796-latest"
}

What does each row contain?

Column	Meaning
runAt, runId, zone	When the run happened and which Make zone it read
organizationId, organizationName, teamId, teamName	Which organization and team the resource belongs to
resourceType, resourceId, name	What it is, Make's own id, and its current name
changeType	added, modified, unchanged, removed, or backfilled for a resource an earlier run missed
diffSummary	One line: 2 modules added, 1 modified, New scenario with 6 modules, No change
moduleCount, modulesAdded, modulesRemoved, modulesModified	Module-level diff, counted across routers, iterators and error handlers
connectionCount, connectionsChanged	How many connections the scenario uses, and whether that set moved
routeCount	Router branches
isActive, isPaused, isLocked, isInvalid	Scenario state. None of these affects the content hash — switching a scenario on is not an edit
scheduleType, scheduleInterval, schedulingChanged	The schedule, and whether it changed this run
contentHash, previousContentHash	What decided changeType
lastEdit	When Make last committed a blueprint version
versionsAvailable, oldestVersionAvailable	How many past versions Make still holds and the oldest date. Populated on runs with seeding enabled
versionsSeeded	How many past versions this run stored
secretsFound	A count of values in the blueprint that look like credentials. Only ever a count
snapshotKey, snapshotUrl	Where the full JSON of this resource is stored

What is in the backup store?

The named key-value store is the restorable copy and it is never pruned:

• scenario-<zone>-<org>-<id>-latest — the current blueprint, overwritten each run.
• scenario-<zone>-<org>-<id>-<date> — a dated copy, written only when the content changed.
• scenario-<zone>-<org>-<id>-v<n> — a past version, when seeding is on.
• <collection>-latest and <collection>-<date> — the same cycle for the other seven resource types.
• manifest-<zone>-<org> — what the next run compares against.

A blueprint fetched at a historical version has a null envelope: Make returns the flow but not the schedule, so a seeded version carries content only and cannot tell you what the schedule was that month.

What does the Git repository look like?

make/
  manifest.json
  scenarios/7461796-summarize-google-document.json
  connections.json
  customVariables.json
  dataStores.json
  dataStructures.json
  hooks.json
  keys.json
  scenarioFolders.json

A commit is made only when the content changed — an unchanged organization produces no commit, so the log stays readable. A deleted or renamed scenario's file is pruned, except on a run narrowed by team or scenario, which cannot tell absence from exclusion and so never prunes.

How much does it cost to back up a Make account?

The Actor is pay per event, at the prices shown on this page.

Event	Charged	When
resource-backed-up	Once per resource	After its snapshot write returns
git-commit-pushed	Once per run	After the push succeeds

The organization these examples come from holds 4 scenarios and 9 other resources, and charged 13 events on its first run — one per resource — plus one for the commit. Unchanged resources are charged, because a verified unchanged copy is the thing a backup is for — paying only for change would pay the Actor for churn instead of coverage. Resources that were deleted are reported and not charged. Seeding charges one event per past version stored, once; a later run does not store them again.

Paste mode charges nothing and makes no network call at all, so you can try the Actor without a Make account or any credit.

Nothing is charged before the write returns, and a run that cannot cover a resource stops rather than delivering it free.

How to run it from the API or from Make

curl -X POST "https://api.apify.com/v2/acts/mediocre_interest~make-scenario-backup/run-sync-get-dataset-items?token=<YOUR_APIFY_TOKEN>" \
  -H 'Content-Type: application/json' \
  -d '{
    "makeZone": "eu1",
    "makeApiToken": "<your Make API token>",
    "include": ["scenarios", "connections"]
  }'

That returns the change rows as JSON. Add &format=csv for a spreadsheet, or &fields=resourceType,name,changeType,diffSummary to keep only the columns you want.

From Make itself, the Apify app has Run an Actor and Get dataset items modules, so a Make scenario can back up your Make account and post the result to Slack. The n8n and Zapier integrations do the same. Apify's scheduler runs it daily, and a webhook on finish can notify you when changeType is anything but unchanged.

Tips for better results

• Turn on seeding for the first run only. It captures whatever Make still holds, and Make's window closes a day at a time. Leaving it on afterwards costs nothing extra — versions already stored are not stored again.
• Use a different backup store name per Make account. The store is the baseline; sharing one between accounts makes the first run of the second account look like a rewrite.
• Choose strict redaction if the repository is public or shared. It masks anything credential-shaped inside a blueprint, which makes the Git copy unrestorable but the stored copy stays faithful.
• Schedule it daily rather than hourly. The dated snapshot is per day, so two runs on one day overwrite each other's dated copy.
• Narrow with Team IDs for an agency. One run per client organization gives each its own history and its own store.

FAQ

Does this change anything in my Make account?

No. The Actor only ever reads. It requests read-only scopes, and it has no code path that starts, stops, edits, creates or deletes a scenario.

Can I restore a scenario from the backup?

Yes. Take the stored blueprint from the key-value store and import it in Make, or paste it into a new scenario. The stored blueprint's name is corrected from the live scenario name on every run, so restoring an old copy cannot silently rename the scenario you restored it into.

Why does the run say "unchanged" for everything?

Because nothing changed, which is the answer a backup should give most days. The Actor compares a content hash that deliberately ignores things that move on their own — operation counters, queue lengths, Make's own advisory messages — so only a real edit is reported.

Does it store my API keys or connection credentials?

No. Make's API does not return connection credentials or key material at all. Values that look like credentials inside a blueprint are counted, never copied into a row, and can be masked out of the Git copy with strict redaction. Custom variable values and webhook URLs are kept in the key-value store so a restore works, and are always blanked in Git.

Does it use an AI model?

No. Every comparison is a hash and a diff, so the same input always gives the same answer and there is no per-run model cost.

How far back can the first run go?

At most 60 days, and only for scenarios where Make still holds the versions. Make archives older versions and its API cannot return them. That limit is the reason to run this on a schedule rather than once.

Why is my e-mail address not in the output?

Because it is deliberately removed. Make returns the name and e-mail of whoever created or last edited a scenario; an Apify dataset is shareable by URL and a Git repository is often public, so none of it reaches a row, a snapshot or a commit.

Can it back up more than one Make organization?

One organization per run. Each gets its own baseline and its own history, so an agency schedules one run per client. Use Organization IDs to pick which.

What other Actors work with this one?

• Make.com Scenario Auditor - Linter & Cost Review — lints a blueprint for wasted operations and risky patterns. It reads the same blueprint JSON this Actor stores, so you can audit any snapshot from your backup history.
• Make.com Operations Usage & Cost Analyzer — shows where your Make operations are actually going.
• Make.com App & Module Catalog - Triggers & Actions — every Make app with its triggers and actions.
• n8n Workflow Backup & GitOps - Version History — the same job for an n8n instance.

Support

Report a problem on the Issues tab. Include the run id and, if you can, the smallest input that reproduces it — a single scenario id is usually enough. Custom work and changes to the output shape are available on request.