IFTTT webhooks: call an API that needs an API key

IFTTT webhooks are the Webhooks service: two triggers that start an applet when a URL receives a web request, and one action, Make a web request, that calls any public URL with a method, content type, body and additional headers. That headers field can carry an API key, so an applet can call an API directly. For a paid API, send the applet to a small endpoint of your own that holds the key instead.

The IFTTT facts come from IFTTT's Webhooks service FAQ, the Make a web request action page and Troubleshooting outbound webhooks. The Sume facts come from Authentication and Create a run. All were read on 2026-09-29. Sume has no official IFTTT service; the call is a plain web request.

Is IFTTT Webhooks free?

No. IFTTT's FAQ says the Webhooks service's two triggers and one action are available on the Pro tier, its three queries on Pro+, and the service is not available on the free tier.

How do I send an API key from IFTTT?

Type it into Additional Headers, for example Authorization: Bearer <key>. It works, but the key then lives in the applet's configuration. Sume's docs say to keep API keys on trusted servers, CI secret stores, or local developer machines, and never in frontend code, mobile apps, tickets or screenshots. For a key that can start paid work, put a server in between.

• The applet calls your endpoint with a secret of your own in a header, such as X-Applet-Secret.
• Your endpoint checks that secret, validates the body, and calls Sume with the real key from an environment variable. Sume's docs describe this server-side proxy pattern and say to validate input before forwarding.
• If the applet secret leaks, rotate it without touching the API key.
• In the Body field, surround ingredients with <<< and >>> so their text can't break the JSON.

What does the endpoint look like?

A route that answers inside IFTTT's 12 seconds: it starts the run and returns. A Sume Format run create answers 202 with a receipt; the result comes later.

import { timingSafeEqual } from "node:crypto";

function allowed(given: string | null) {
  const secret = Buffer.from(process.env.APPLET_SECRET ?? "");
  const got = Buffer.from(given ?? "");
  if (secret.length === 0 || got.length !== secret.length) return false;
  return timingSafeEqual(got, secret);
}

export async function POST(request: Request) {
  if (!allowed(request.headers.get("x-applet-secret")))
    return new Response("forbidden", { status: 403 });
  const { item_id, instruction } = await request.json();
  if (typeof item_id !== "string" || typeof instruction !== "string")
    return new Response("bad request", { status: 400 });
  const res = await fetch("https://api.sume.com/v1/formats/acme/product-promo/runs", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${process.env.SUME_API_KEY}`,
      "Content-Type": "application/json",
      "Idempotency-Key": `ifttt-${item_id}-v1`,
    },
    body: JSON.stringify({ instruction }),
  });
  return new Response(await res.text(), { status: res.status });
}

Why key each request on the item?

The same item can reach your endpoint twice, and a timeout doesn't tell you whether a request arrived. Sume's docs say to derive the Idempotency-Key from the thing being made; the same key with the same body returns the original run, with no second run and no second charge. A random key per request makes the header decorative.

An applet can't wait minutes for a video. Set communication.webhook_url on the run to an HTTPS endpoint you run, and Sume posts there once when the run completes or fails.