Make's ChatGPT plugin runs scenarios: return the Sume job id

If you ask ChatGPT to run a Make scenario that calls Sume, what should the scenario hand back? The job id, immediately, and nothing that waits for the render. Make announced an official Make plugin for ChatGPT on September 9: from ChatGPT you can describe, build and run automations, search them, review output and browse execution history, with results shown as tables and status badges, on all plans (read 2026-10-04). A chat is a poor place to sit through a long render, and Sume's API is built so you never have to.

The pattern is two scenarios. One submits the job and returns the id. The other takes an id and reports status. ChatGPT calls whichever one the conversation needs.

Why the first scenario returns early

Sume job requests default to async mode. A 202 response means the job was accepted, not finished, and the body carries the identifiers to follow it. Waiting inside the scenario for a video to render turns a one-second action into a long one and, in a chat, looks like a hang.

So the submit scenario ends right after the HTTP module. It maps three values out: the job id, the status URL, and the Idempotency-Key you sent. Showing the key in the result means that if you ask ChatGPT to run the scenario again for the same input, you can see that the second run returned the same job instead of creating another paid one.

The submit request

In Make, add an HTTP module that makes a request to https://api.sume.com/v1/images with method POST. Send one auth header, x-api-key, or Authorization: Bearer, never both, because Sume answers a doubled credential with 401 unauthorized. Store the key in a Make connection or keychain entry rather than in the module text.

The equivalent request is below, written as a Node script so you can test the body before pasting it into Make. It uses model: "sume/auto", which the image docs recommend over the older Image 1.0 alias, and prints only the fields you want the scenario to return. The idempotency key is derived from the input, so repeating the same prompt returns the original job.

import { createHash } from 'node:crypto';

const key = process.env.SUME_API_KEY;
if (!key) throw new Error('SUME_API_KEY is not set');
const prompt = 'A paper boat on a calm lake at dawn';
const idem = 'make-' + createHash('sha256').update(prompt).digest('hex').slice(0, 24);

const res = await fetch('https://api.sume.com/v1/images', {
  method: 'POST',
  headers: {
    'x-api-key': key,
    'content-type': 'application/json',
    'idempotency-key': idem,
  },
  body: JSON.stringify({ model: 'sume/auto', prompt }),
});
const body = await res.json();
console.log(res.status, idem);
console.log(JSON.stringify(body, null, 2));

The status scenario

The second scenario takes the job id as an input and calls GET /v1/jobs/:id/status. Return the status and the next_poll_after_seconds value so the person in the chat knows when to ask again. Terminal statuses are completed, failed and canceled. When the status is completed, call GET /v1/jobs/:id/result and return the artifact URL, which points at media.sume.com.

Keep this scenario read-only. It spends nothing, so it is safe for ChatGPT to run repeatedly, and it keeps the paid action in exactly one place.

Guardrails for a chat-driven scenario

A chat can trigger a scenario more times than you intended, so the paid one needs protection that does not depend on the conversation behaving. The idempotency key covers repeats. For a cap on spend per request, Sume's format runs accept generation_spend_cap_usd, and the hosted tool surface offers dry_run and max_spend_usd. See the post on idempotency keys in Make's AI agent fallback for the retry side, and the one on scenario tools and their timeouts for why the early return matters.

Finally, review what ChatGPT can see. The plugin shows output and execution history, so anything your scenario returns can end up in a chat. Return ids and URLs, not keys, and rotate any key that ever appears in one.