Lambda async 1 MB limit vs Sume's 1 MiB run webhook overflow

Lambda accepts 6 MB for a synchronous request or response and 1 MB for an asynchronous event, while Sume delivers a run webhook inline up to 1 MiB and otherwise sends payload: null with a result_url. If you forward the webhook body into a Lambda asynchronously, it fits only just; forward the run id and fetch the receipt in the worker.

What are Lambda's payload limits?

The Lambda quotas page lists invocation payload per request and per response: 6 MB each for synchronous invocation, 200 MB for a streamed synchronous response, and 1 MB for asynchronous invocation. It also states 1 MB for the combined request line and header values. Lambda's docs use MB for 1,024 KB.

A Function URL invocation is synchronous, so a webhook POST to a function URL has the larger 6 MB room. A hop through an asynchronous path, such as an event invoke from another service, has 1 MB.

What does Sume do with a large receipt?

A run receipt over 1 MiB cannot be delivered inline, per the run webhooks page. Sume sends the envelope with payload: null and an error carrying code: payload_too_large and the result_url to fetch. The run did not fail; status still reports the true outcome.

Structured output and per-scene artifact lists are what grow a receipt, so a long Format with many artifacts is the realistic way to hit this.

How should the Lambda be shaped?

Two small functions beat one big one. The receiver verifies the signature on the raw body, stores the event keyed by request_id, and returns 204. A worker, triggered by whatever async path you prefer, receives only the id and fetches result_url with your API key.

A Function URL event can arrive base64 encoded, shown by isBase64Encoded, so decode before verifying. Verify against the exact raw bytes: a parsed and reserialized body will not match the signature.

import { verifyWebhook } from "@sume-com/sdk";

export const handler = async (event: {
  body: string;
  isBase64Encoded: boolean;
  headers: Record<string, string>;
}) => {
  const secret = process.env.SUME_COM_WEBHOOK_SIGNING_SECRET;
  if (!secret) return { statusCode: 500, body: "secret not set" };
  const body = event.isBase64Encoded
    ? Buffer.from(event.body, "base64").toString("utf8")
    : event.body;
  const ok = await verifyWebhook({ body, headers: event.headers, secret });
  if (!ok) return { statusCode: 401, body: "bad signature" };
  const e = JSON.parse(body);
  // store e.request_id durably here, then hand only the id to the next step
  return { statusCode: 204 };
};

Why is this safe against retries?

Sume makes up to 10 attempts, with a 10-second timeout each, and treats any non-2xx, redirect or timeout as a failed attempt. request_id is the same on every retry, so use it as your dedupe key, and use created_at if you need ordering. A receiver that stores before it forwards never loses an event and never forwards the same id twice.

Keep a fallback: if a delivery never arrives, status_url and result_url still answer, and Redeliver on the dashboard re-sends a real terminal event.

What does Sume not do?

Sume does not ship you a thinner payload on request, and there is no setting to choose inline or fetch. The 1 MiB boundary is fixed and your code has to handle both. It also does not run inside your account: the Lambda, its quotas and its IAM are yours.