SNS 1 MiB messages and Sume run webhook fan-out

Sume run webhook bodies are capped at 1 MiB, and SNS now allows 1 MiB messages with MaximumMessageSize. Ack the webhook first, then publish.

4 min readSume
All posts

A Sume run webhook can be fanned out through SNS only if the topic accepts messages that large. Amazon SNS announced payloads up to 1 MiB on September 18, 2026, via the MaximumMessageSize topic attribute, and Sume delivers run receipts inline up to 1 MiB. Your receiver should still return 2xx first, then publish.

Facts are from the AWS announcement and Sume's Run webhooks page, read 2026-09-30.

What are the two limits?

SNS and Sume payload limits, read 2026-09-30.
SideLimit as written
SNS before the change256 KiB
SNS nowUp to 1 MiB, set with the MaximumMessageSize topic attribute (Standard and FIFO)
SNS subscriptions above 256 KiBAmazon SQS, Amazon Data Firehose and AWS Lambda; up to 100 per topic
Sume run webhook body1 MiB; larger receipts arrive with payload: null
Sume overflow message"Run receipt exceeded the 1048576-byte webhook body limit."

Does a full run receipt fit in one SNS message?

The Sume payload is the full receipt, byte-identical to the data object of GET /v1/{family}-runs/{run_id}, wrapped in an envelope. Both ceilings are stated as 1 MiB, so a body near Sume's cap may not fit once you add anything of your own. Publish the verified body as-is, keep any wrapper small, and expect the occasional oversized case.

What happens to an oversized receipt?

Sume sends the envelope with payload: null and an error whose code is payload_too_large, carrying a result_url. status still reports the real outcome: a run that succeeded and was too large to ship did not fail. Fetch from result_url instead of publishing a null payload. The details are in oversized receipts.

Where does SNS go in the receiver?

Verify the signature on the raw body, record the event durably, return 2xx, and only then publish. The docs say to return 2xx quickly, after durably recording the event, because the timeout is 10s per attempt and a slow endpoint burns the budget and gets retried. A publish that fails after you have stored the event can then be retried from your own store.

Dedupe on request_id, which equals the run id and is stable across retries. Subscribers downstream of SNS should dedupe on it too, since SNS and Sume retries are independent.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume