Why do Stripe's messages to my app get 401 "Authentication Required"?

Stripe sends each webhook as a plain POST with a Stripe-Signature header. It can't sign in, can't send a Supabase key and can't add your own headers. So any layer in front of your code that asks for a login answers 401, and your code never runs. Stripe's docs list 401 among the responses you get "when the destination URL has access restrictions".

Three layers usually do this:

1. Read the 401 body in Stripe. In the Stripe Dashboard, open Workbench → Webhooks, select your endpoint and open Event deliveries. Click a failed delivery and read the response body. It tells you which row of the table above applies. Note the exact endpoint URL too.

You can also reproduce it from a terminal. A 401 to a request with no Stripe headers confirms the block is in front of your code:

curl -i -X POST "https://YOUR-WEBHOOK-URL" -H "Content-Type: application/json" -d '{}'

Once the block is gone, the same request should get a 400 from your own code, because there's no valid signature. That's the result you want.

2a. Vercel: use your production domain, or add the bypass secret.

• Best fix: set the Stripe endpoint to your production domain, such as https://yourapp.com/api/stripe/webhook. With Standard Protection, production domains need no login.
• If the project uses "All Deployments", or you need a preview URL to receive webhooks, use Vercel's Protection Bypass for Automation. Create a secret in the project's Settings → Deployment Protection and add it to the endpoint URL as a query parameter. Vercel's docs give this exact Stripe example:

https://your-app.vercel.app/api/stripe-webhook?x-vercel-protection-bypass=YOUR_SECRET

• Treat that URL as a secret. If you regenerate or delete the bypass secret, redeploy and update the URL in Stripe.
• Don't switch Deployment Protection off for the whole project just for this.

If Stripe shows a 307 or 308 instead of a 401, the request is being redirected, for example from yourapp.com to www.yourapp.com. See Stripe webhook failing with a 307 or 308 redirect.

2b. Supabase Edge Function: turn off the JWT check for the webhook function only. Stripe can't send a Supabase key, so the webhook function has to skip the built-in check and rely on the Stripe signature instead. Supabase's own Stripe example says: "Stripe verifies the request via its signature, so deploy with verify_jwt = false". Supabase now calls this check legacy and recommends handling auth in your function code. Pick one way:

• In supabase/config.toml (Lovable and Bolt projects use this file), add a block for the webhook function, then redeploy it:

[functions.stripe-webhook]
verify_jwt = false

• Or deploy with the CLI flag:

supabase functions deploy stripe-webhook --no-verify-jwt

• Or in the Supabase Dashboard, open Edge Functions, open the function's details and turn off JWT verification.

Use your own function's name in place of stripe-webhook. Only do this for the webhook. Functions your app calls from the browser should keep checking who the caller is.

2c. Your own middleware: exclude the webhook route. Find the middleware or route guard that returns the 401 and exclude the webhook path. In Next.js that usually means adding the path to your list of public routes, or changing the matcher in middleware.ts (or proxy.ts) so it skips /api/stripe/webhook. The webhook route must not require a session cookie or a signed-in user.

Removing the login check is safe only if the handler checks that each request really came from Stripe. Read the raw body and verify the Stripe-Signature header with the endpoint's whsec_ signing secret. Stripe's docs warn that "any manipulation to the raw body of the request causes the verification to fail". In a Supabase Edge Function (Deno), use the async version with the Web Crypto provider, as Supabase's example does:

import Stripe from 'npm:stripe@^22'

const stripe = new Stripe(Deno.env.get('STRIPE_SECRET_KEY')!)
const cryptoProvider = Stripe.createSubtleCryptoProvider()

export default {
  fetch: async (req: Request) => {
    const signature = req.headers.get('Stripe-Signature') ?? ''
    const body = await req.text() // raw body: don't use req.json() here
    let event
    try {
      event = await stripe.webhooks.constructEventAsync(
        body,
        signature,
        Deno.env.get('STRIPE_WEBHOOK_SECRET')!,
        undefined,
        cryptoProvider,
      )
    } catch (err) {
      return new Response(`Webhook signature error: ${(err as Error).message}`, { status: 400 })
    }
    // handle event.type here, then:
    return Response.json({ received: true })
  },
}

We tested this code with stripe-node 22.6.2. A correctly signed payload passed. A re-serialised body and a wrong secret were both rejected with StripeSignatureVerificationError. The test and live endpoints have different whsec_ secrets, so use the one for the endpoint that is failing. If you now see "No signatures found matching the expected signature", see Stripe webhook "No signatures found".

Fixing the endpoint doesn't replay the events that already failed. In live mode, Stripe retries a failed delivery for up to three days, with longer gaps each time. In a sandbox it retries three times over a few hours. You can also resend events yourself:

• In the Stripe Dashboard, open the event and click Resend. This works for up to 15 days after the event was created.
• With the Stripe CLI, run stripe events resend <event_id> --webhook-endpoint=<endpoint_id>. This works for up to 30 days.

Resend the payments that failed, then check that your database caught up. Your handler may now get the same event twice (your resend and Stripe's retry), so skip event IDs you have already processed.

Paste this into Lovable, Bolt, Cursor, Claude, ChatGPT, Replit, v0 or whichever tool you build with. Replace the bracketed parts first.

My Stripe webhook endpoint returns 401 for every delivery. The endpoint URL is [PASTE URL], and the 401 response body Stripe shows is [PASTE BODY].
Please fix it without changing unrelated code:
1. If this is a Supabase Edge Function, set verify_jwt = false for the webhook function ONLY in supabase/config.toml ([functions.FUNCTION_NAME]) and tell me how to redeploy it. Leave the JWT check on for every other function.
2. If this is a Next.js or Vercel route, make sure the webhook path is excluded from any auth middleware (middleware.ts or proxy.ts) or route protection, and tell me whether I should point Stripe at my production domain instead of a preview URL.
3. In the webhook handler, read the raw request body (req.text(), not req.json()) and verify the Stripe-Signature header with the webhook signing secret from an environment variable. In Deno or Edge runtimes use await stripe.webhooks.constructEventAsync(..., Stripe.createSubtleCryptoProvider()). Return 400 if verification fails, and 200 only after the event is handled.
4. List every environment variable or secret the handler needs and where I must set it.
Don't disable RLS or remove auth from any other route.

1. Run the curl command from step 1 again. You should get a 400 from your own code (no valid signature), not a 401.
2. In a Stripe sandbox, run stripe trigger checkout.session.completed with the Stripe CLI and check that the sandbox endpoint's Event deliveries show 200.
3. For the live endpoint, resend one real failed event. Check that it shows 200 and that the customer's plan or order updated.

Webhook 401s often start after a redeploy, a move to a new Vercel project, a change to Deployment Protection, or an AI edit that rewrites config.toml or the middleware. Payments still go through, so nothing looks wrong on screen.

Heedza never pays, so it can't see webhook deliveries. Stripe's Event deliveries tab and Stripe's emails about failing webhooks are where these show up. What Heedza does check on a schedule is that your landing, signup, login and checkout pages load and show their forms and pay buttons. It sends you a screenshot and a fix prompt when one of them breaks.