Mutator and Make

Make videos and pictures from a Make scenario, and start a scenario when Mutator has made something.

Nothing here publishes anything. No module reaches a social account, because there is no endpoint in Mutator's API that schedules a post. A post exists once a person has put a particular file in a particular account's schedule, in Mutator, with their name against the decision.

Where it stands

The Mutator app is written and is not published yet. Everything below works today with Make's own Custom webhook and HTTP modules, against the same API the app uses.

Connecting

Settings → API keys → New key in Mutator. Keys come with any paid plan and the secret is shown once. The connection is labelled with the workspace's name, so two workspaces connected at once are told apart.

A read key is enough for the triggers and searches. The three actions that make things need a write key.

Automations are a Growth feature, so on Pro there are none to list and none to run. Everything else works on any paid plan.

Instant triggers

Four, each attached as a webhook when you switch the scenario on and detached when you switch it off: a video or picture was made, an automation run finished, a generation finished, or a post somebody scheduled went out.

The first three read the thing the delivery names rather than passing the delivery on. A delivery carries ids and no links, because it can sit on a queue while a receiver is down, and a signed link that old is a broken scenario.

Watch posts published is the exception, and needs no fetch: a post is already fully described by its delivery, so the fields arrive as they are. Nothing in this app publishes anything; this reports what a person decided in Mutator. GET /api/v1/posts has the same rows if you want to read back over them.

Doing it today, without the app

Add a Webhooks → Custom webhook module, copy its URL, and subscribe it once:

curl -X POST https://mutator.app/api/v1/hooks \
  -H "Authorization: Bearer loop_sk_..." \
  -H "content-type: application/json" \
  -d '{"event": "media.created", "targetUrl": "YOUR_CUSTOM_WEBHOOK_URL"}'

The events are media.created, run.finished, generation.finished and post.published. The reply carries a secret, and every delivery is signed with it; the API documentation has the check to run before trusting one. DELETE /api/v1/hooks/{id} stops it.

Follow the webhook with an HTTP → Make a request on /api/v1/media/{id} to read the file the delivery names.

Modules

Ask for a video or picture. It answers at once with an id, because a clip takes minutes and a module that waits is one that times out. Use the generation trigger, or a Sleep and then a search.

Start an automation. Runs one you have already built and switched on.

Add a picture from a URL. So a generation can paint from it. PNG, JPEG, WebP or GIF, up to 32 MB, from a public link. It answers status: checking, because everything arriving goes past the content check first.

List videos and pictures, and list automations, for the searches.

Doing it today, without the app

HTTP → Make a request, with your key in the Authorization header. Every endpoint is in the API documentation.

The idempotency key, which every action asks for

Every write in Mutator's API takes one, because a request that timed out after the work started looks exactly like one that timed out before it, and the work is a video somebody paid for.

Zapier and n8n each hand an integration something stable to build a key from. Make does not expose a per-execution id the app can rely on, and a key that changed on every retry would be the same as having none, so the app asks for one instead.

Map something that identifies the thing that started the scenario: the row id, the file id, the record id. Mutator answers a repeat of the same key with the first answer rather than making a second video.

Limits

120 reads and 30 writes a minute, per key. Download links last six hours: fetch the bytes rather than storing the link.