← Documentation

Mutator and n8n

Make videos and pictures from an n8n workflow, on your own machine, and start a workflow when Mutator has made something.

Nothing here publishes anything. No operation 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

n8n-nodes-mutator is written and is not on npm yet. Everything below works today with n8n's own HTTP Request and Webhook nodes, against the same API the node uses.

When it is published: Settings → Community nodes → Install, n8n-nodes-mutator, on your own n8n. On n8n Cloud, only once the node is verified, which needs a publish carrying an npm provenance statement.

Connecting

Settings → API keys → New key in Mutator. Keys come with any paid plan and the secret is shown once. The credential takes the key and, if you are pointing at something other than production, a base URL.

A read key is enough for the trigger and the searches. The operations 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.

The trigger polls, on purpose

Mutator delivers signed webhooks, and the trigger node asks instead. Most n8n runs on somebody's own machine or inside their own network, where a webhook from the outside cannot reach it, and a trigger that only works for the reachable half is one that fails silently for everybody else.

It watches one of four things: a video or picture was made, an automation run finished, a generation finished, or a post somebody scheduled went out. That last one polls /api/v1/posts and follows publishedAt, which is that record's clock; the node cannot publish anything, it hears about it.

Three things it does that are worth knowing:

  • The first tick says nothing. Switching a workflow on records where the list is rather than replaying everything the workspace has ever made.
  • Runs and generations have to have finished. A poll two minutes into a five minute video would otherwise announce it and hand the next node no file.
  • Two things made in the same millisecond are two things. It compares on the time and the id together, so neither is repeated or lost.

If your n8n is reachable, use webhooks instead

Put a Webhook node in the workflow, copy its production 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": "https://your-n8n/webhook/abc"}'

The events are media.created, run.finished, generation.finished and post.published. The reply carries a secret; every delivery is signed with it in a mutator-signature header, as t=…,v1=…, an HMAC-SHA256 of ${t}.${body}. The API documentation has the check to run before trusting one. DELETE /api/v1/hooks/{id} stops it.

A delivery carries ids rather than links, so follow it with an HTTP Request on /api/v1/media/{id} to read the file.

What the node does

Generation: ask for a video or picture, get one, list them. Asking answers at once with an id, because a clip takes minutes and a node that waits is one that times out. Use the trigger, or a Wait node and then Generation → Get.

Media: get one, list them. Getting one reads it now, so the download link is signed now.

Automation: list them, run one.

Picture: add one from a URL, so a generation can paint from it. It answers status: checking, because everything arriving goes past the content check first.

Doing it today, without the node

HTTP Request, with a Generic credential of type Header Auth: Authorization / Bearer loop_sk_.... Every endpoint is in the API documentation.

Retries, and the idempotency key

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. The node fills it in from the execution id and the run index, which a retried execution keeps, so a retry is the same request rather than a second video. Set the field yourself where one workflow legitimately asks for the same thing twice.

Limits

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