Skip to content

Supabase Edge Functions errorSupabase Edge Functions: 401 “Invalid JWT” or “Missing authorization header”

A 401 Invalid JWT is the Supabase Edge Functions error that the platform’s verify_jwt check returns before your code runs. The Authorization header is missing, malformed, or holds a token the check rejects, so your function never executes.

Short answer

Read the response body: Invalid JWT or Missing authorization header comes from the platform check, not your code. Call the function with supabase.functions.invoke from a signed-in client. For webhooks, cron and server calls, set verify_jwt = false for that function and check the caller in code. Don’t turn it off just to silence the error on a function users call.

Rather not fix it yourself? App Fix Ticket starts with a fixed-price diagnosis, then a fixed price for the fix before any fix work.

Why the function returns 401, and the fix

  1. 01

    The request has no user token

    “If the header is missing, malformed, or signed with a different key, the platform returns a 401 error, and your code never executes.” Supabase docs, Authorization headers (verify_jwt)

    A plain fetch without headers, or a call made before the session loads, sends no user JWT. Use supabase.functions.invoke after sign-in, which adds the token for you.

  2. 02

    A webhook or cron job calls it

    “Supabase now recommends turning off this built-in check and managing authentication directly in your function code, giving you more control over access.” Supabase docs, Edge Function 401 error response

    Stripe, cron and other servers don’t send a Supabase user token. Turn the check off for that one function, then verify the caller in code, such as the webhook signature or a secret key, or the function is open to anyone.

    # supabase/config.toml
    [functions.stripe-webhook]
    verify_jwt = false
  3. 03

    The project uses the new signing keys

    “However, the legacy auth verification check only understands the legacy format.” Supabase docs, Edge Function 401 error response (Incompatible key format)

    Supabase’s troubleshooting guide says the built-in check can reject projects on the new asymmetric keys. Turn JWT verification off for that function in the dashboard, or redeploy with --no-verify-jwt, then check the caller in code.

  4. 04

    An API key is sent as a Bearer token

    “Sending the wrong credential in the wrong header is the most common source of 401 errors.” Supabase docs, Authorization headers

    The new sb_publishable_ and sb_secret_ keys are not JWTs. The platform check lets them through, but a handler that verifies the header as a JWT returns its own 401. Put keys on the apikey header and keep Authorization for a signed-in user’s token.

  5. 05

    Your own code returned the 401

    “If the response body contains a message you coded, or nothing at all, then your function code did execute and returned a 401 itself.” Supabase docs, Edge Function 401 error response

    A custom message or an empty body means the request passed the platform check. Look at the auth logic in your handler instead.

Checked against the vendor’s docs on : Supabase docs: Authorization headers; Supabase docs: Securing Edge Functions; Supabase docs: Edge Function 401 error response.

Rather hand it over?

Fixed scope, fixed price, paid upfront. The work happens in writing; no call needed.

“Very responsive, attentive to fixing bugs, and completed the project as needed! Thank you!”
A buyer in the United States, July 2022. Shopify on Fiverr
All 127 Fiverr reviews

Related: Supabase Edge Function non-2xx status code · Supabase Edge Function CORS error · Supabase JWSError JWSInvalidSignature · Supabase Edge Function timeout

Questions

More on this error

Is it safe to turn off verify_jwt?

Only when your code checks the caller instead, such as a webhook signature or a secret key. Otherwise anyone with the URL can call the function.

Why did this start after I switched to the new API keys?

Two things can change. Supabase’s troubleshooting guide says the built-in check can reject projects on the new asymmetric keys; turn verify_jwt off for that function and check the caller in code. And the new keys are not JWTs, so send them on the apikey header.

Can you fix it for me?

If one bug is the whole problem, the App Fix Ticket covers it: a written diagnosis first, then the fix. If the app has more going on, the Launch Check is a written check of the whole app. Each issue found is rated critical, high, medium or low, with where it is and how it was confirmed. No issues worth fixing, no charge. If the Launch Check finds nothing rated medium or higher, Simon refunds the full $450. You keep the report either way. This applies to the first 10 Launch Checks bought after October 30, 2026.

A different error?

Describe it and get a written quote

Send the error and what you were doing. You get a written scope, a fixed price and a timeline; Simon replies by email, usually within one business day.