Cloudflare Access 302 to login is not a Sume webhook delivery

Strict service token auth returns 401 or 403 instead of a 302 login redirect, but Sume never sends a service token. What a 3xx on your webhook URL costs you.

5 min readSume
All posts

If your Sume webhook URL sits behind Cloudflare Access, a request with no session gets a 302 to the login page, and Sume counts that as a failed attempt: Sume's run-webhook docs say redirects are not followed and a 3xx is not a delivery, and the job-webhook docs say non-2xx responses are retried until attempts run out. Cloudflare's strict service token authentication, announced on 2026-10-02, changes the failure for service-token requests to a 401 or 403, but it does not make the URL reachable by Sume, because the headers Sume sends do not include a service token.

The facts come from Cloudflare's changelog entry and Sume's Webhooks, Run webhooks and Jobs and results pages, all read on 2026-10-03. I did not run a Sume webhook against an Access-protected URL, so the unprotected-path advice below is a conclusion from those pages, not a test.

What does strict service token authentication change?

Per the changelog, when the setting is on, a failed authentication or authorization for a service-token request returns 401 or 403 rather than a 302 to the login page. Only Service Auth policies can authorize the request; Access ignores Allow policies and any CF_Authorization cookie sent with it. Access also stops returning a CF_Authorization cookie after a successful service-token request, and failed requests for recognized service tokens appear in Access authentication logs.

Organizations created on or after 2026-10-05 get it on by default and cannot turn it off; older organizations can opt in from the Access settings or with strict_service_token_auth in the organizations API.

Strict service token behavior from Cloudflare's changelog entry, read 2026-10-03.
BehaviorWith strict service token auth
Failed service-token request401 or 403, never a 302 to login
Which policies authorizeService Auth policies only; Allow policies are ignored
CF_Authorization cookieNot issued after success; keep sending the token headers
LoggingFailures for recognized tokens appear in Access authentication logs
DefaultOn for organizations created 2026-10-05 or later; opt-in before that

What does Sume send to a webhook URL?

Sume's job and run webhooks carry content-type, x-sume-webhook-timestamp, x-sume-webhook-signature: sume-v1=<hex> and x-sume-webhook-secret-fingerprint. None of those is an Access service token, and the docs describe no way to add custom headers to a delivery. So the receiver is authenticated by the HMAC over <timestamp>.<raw_body>, not by Access.

In practice that means the receiving path has to be reachable without an Access login. Whether a Bypass policy on that one path is the right way to do it is a Cloudflare question I did not test; the safe part is that your handler verifies the signature with a 300-second tolerance and rejects anything else.

What does a failing Access URL cost in Sume attempts?

Job webhooks make up to 10 attempts, 30 seconds apart by default, with a 10-second timeout each, so nine gaps is about four and a half minutes before delivery is exhausted. Run webhooks also stop at 10 attempts, with exponential backoff capped at one hour. In both cases the job or run itself still reaches its real terminal state; only the delivery fails.

Recovery does not need the original attempts. POST /v1/jobs/{job_id}/webhook/redeliver re-sends a job's terminal event with a fresh timestamp and signature, and it does not consume one of the automatic 10. Keep status_url polling as the backup, and dedupe on job_id for jobs or request_id for runs.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume