webcrypto_modern_algorithms flag: verifying a Sume webhook
Sume's verifyWebhook runs on plain WebCrypto in Workers. The docs list no compatibility flag for it, so webcrypto_modern_algorithms is not a step to add.

You do not need to add the webcrypto_modern_algorithms flag to verify a Sume webhook. Sume's docs describe verifyWebhook as built on WebCrypto instead of node:crypto, list Cloudflare Workers as a supported runtime, and mention no Workers compatibility flag. Leave your Wrangler config as it is and await the check.
Cloudflare's changelog tells you to turn on the webcrypto_modern_algorithms compatibility flag to use the features it announces. Sume's side is from Verifying webhooks, read 2026-09-30.
What does the Cloudflare flag change?
The changelog page I read shows one configuration change: add webcrypto_modern_algorithms to compatibility_flags in your Wrangler config, and the new Web Crypto features become available. The page text I captured does not describe what an existing Worker gets if it never sets the flag, so this post makes no claim about that beyond what Sume's own docs say.
{
"$schema": "./node_modules/wrangler/config-schema.json",
"compatibility_flags": ["webcrypto_modern_algorithms"]
}What does Sume's verifier need from the runtime?
Sume signs each delivery with HMAC SHA 256 over <timestamp>.<raw_body>. The SDK page says the implementation uses WebCrypto rather than node:crypto, which keeps the package importable from Workers, Deno and bundlers that refuse node: specifiers. The SDK page lists the requirement as fetch and WebCrypto, on Node 18+, Bun, Deno or Cloudflare Workers.
| Property | Behavior in the docs |
|---|---|
| Crypto API | WebCrypto, not node:crypto |
| Calling style | async: you must await it |
| Bad input | Returns false instead of throwing |
| Comparison | Constant-time |
| Replay window | toleranceSeconds, default 300 |
| Compatibility flag | None listed |
What does a Worker handler look like?
Read the raw body first, pass it with the headers, and return 401 on false. The secret is SUME_COM_WEBHOOK_SIGNING_SECRET, from the dashboard Webhooks tab or GET /v1/webhooks/signing-secret.
import { verifyWebhook } from "@sume-com/sdk";
export default {
async fetch(request: Request, env: { SUME_COM_WEBHOOK_SIGNING_SECRET: string }) {
const body = await request.text(); // raw, before any JSON.parse
const ok = await verifyWebhook({
body,
headers: request.headers,
secret: env.SUME_COM_WEBHOOK_SIGNING_SECRET,
});
if (!ok) return new Response("bad signature", { status: 401 });
const event = JSON.parse(body);
console.log(event.event);
return new Response(null, { status: 204 });
},
};When would I turn the flag on anyway?
Turn it on when you want a feature from Cloudflare's announcement in your own code. Nothing in the Sume webhook flow asks for it. If a verification fails after a config change, check the usual causes first: a parsed-and-reserialized body, a missing await, or the wrong secret. Debugging Sume webhook delivery walks through them, and Workers queues for video webhooks shows where the verified event goes next.
Sources
Related posts
More in Developers
- xAI video status done/expired vs Sume completed/failed
xAI's Grok Imagine video status values are pending, done, expired and failed. Sume uses pending, in_progress, completed, failed and cancelled. Port a poll loop.
- Zapier Catch Hook test trigger with Sume Send test
Zapier lists the three most recent webhooks from the past hour. Use Sume's Send test to put a signed webhook.test sample there before a real run exists.
- Will a 100-item Sume bulk run hit Zapier's webhook rate limit?
A Sume bulk queue holds up to 100 items, each with its own webhook. Compare that with Zapier's per-Zap webhook limit and know what Sume does on a 429.
- Zapier accepted my Sume webhook but the Zap ran minutes later
Zapier says it may return 200 and delay webhook processing by minutes. Sume sees a delivered 200, so keep a status poll as the backup for run and job results.
Written by Sume