"No API key found in request" in Supabase, and the wrong fix

Your app worked yesterday. Today a list that used to fill with rows is empty, and when you open the browser console there is a short reply from Supabase sitting where the data should be:

{
  "message": "No API key found in request",
  "hint": "No `apikey` request header or url param was found."
}

That is all you get. It does not say which table you were reading, what you sent, or what to change.

Here is the part that guide after guide gets wrong: "No API key found in request" is about a missing header, and most of the advice you will find is about your database rules. On Supabase's own discussion board this message has a thread to itself, sixteen people offer eight different remedies in it, and three of them say to add or loosen a rule on one of your tables. Everyone who tried that reports the message stopped. Whether a rule was ever the cause is a separate question, and the thread never settles it. What is certain afterwards is that more people can read the table than could before.

What "No API key found in request" means

Supabase turned your request away at the front door, before your database was asked for anything.

Every request to your project arrives first at a gateway that Supabase runs in front of everything else. Its job at that moment is narrow: read the apikey header, check the value against the keys your project has, and pass the request on. With no key to read it stops there and answers 401, the status code for "I do not know who you are". Supabase's own gateway reference says a missing or invalid key is refused that way.

Think of the gateway as a doorman at the street door rather than a lock on a filing cabinet. The doorman asks everyone arriving to show a pass. The rules that decide who may open which cabinet live two floors up, and in this case nobody consulted them, because nothing got past the entrance.

So as errors go, this one is mild. Nothing was read, nothing was written, and your data is exactly as it was. A request was refused.

Why did my request arrive without a key?

Because the value your app was supposed to send was not in the request your browser actually made. Four causes cover nearly all of these.

The key never made it into the built app. Your code reads it from an environment variable, the build that produced your live site did not have that variable set, and createClient was handed an empty string. Everything compiles, the app loads, and every request leaves without a key. In a Vite or Next project the variable also has to carry the prefix that marks it safe for the browser, which is a trap of its own.

You are calling the REST path by hand. A fetch written against /rest/v1/your_table sends the headers you typed and nothing else. Supabase's client library adds apikey for you; a hand-written request has whatever you gave it.

Something in between dropped it. A rewrite rule, a proxy or an API gateway of your own sits between your app and Supabase and forwards the request without the header.

You are looking at a redirect rather than a data request. If the message appears after somebody signs in or clicks a confirmation link, and the address bar still shows your Supabase URL, the setting to look at is the Site URL under Auth. The most reacted answer on that whole Supabase thread is somebody who had written their site address there without the https:// in front of it.

The fix, in one line

Send your publishable key in the apikey header.

import { createClient } from '@supabase/supabase-js'

export const supabase = createClient(
  'https://your-project.supabase.co',
  'sb_publishable_…',
)

Create the client that way and the library puts the key in the right header on every request it makes, so you never type the header at all. Supabase's reference is specific about which header that is: publishable and secret keys travel on apikey rather than on Authorization: Bearer, because they are short opaque strings and anything that tries to verify one as a JWT fails.

That key is supposed to be in your app. It says which project a request belongs to, and what a visitor holding it can reach is decided by the rules on your tables, which is the whole reason it can be public in the first place. Which API keys are safe in your frontend covers the rest of the family.

The fix that makes this worse

The secret key fits the same header, and on an older project it will clear the message and go on working.

That is one misplaced click. Your dashboard lists both keys on the same page, and the older pair look alike: same shape, same length, one under the other. How bad the click is depends on which pair your project issues.

A newer secret key is refused in a browser. Supabase blocks sb_secret_… by matching on the User-Agent header and answers 401. Pasting one into your frontend therefore does not clear the error, which is the best outcome on offer here.

A legacy service_role key has no such block. It works. The list fills, the app behaves exactly as it did last week, and the key now sits in a file any visitor can download. There it ignores every rule you have written: service_role carries Postgres's BYPASSRLS attribute, so a policy never applies to it. Every row in every table, readable and writable by whoever opens the file.

Supabase's note on the browser block is worth reading twice. The block answers 401, and an attacker can still use the key from other tools. What it protects is your app's own requests; the same key in the same file answers a request sent from a script.

The other wrong turn, and why it is so easy

Loosening a rule on the table will also stop the message, and it changes who can read your rows.

Here is that Supabase thread in full, grouped by what each answer asks you to change:

The last row is the one that answers the hint in the message. It is the bottom comment on the thread and it has a single vote.

None of the other seven is written in bad faith, and that is what makes this hard. One message really does appear in several situations, the person answering really did get their own app working, and a policy that was already missing is a real thing to fix. What goes wrong is the order: a rule gets rewritten to clear a message about a header, and the rule is the only part of that pair nobody checks afterwards. Your app works either way, so nothing tells you which one you did.

From outside, the result is visible. Our scanner reads live apps the way a stranger would, and of the 31,056 apps it has graded, three published a Supabase secret key. That makes it the rarest finding we hold and the most serious one.

The instinct next to it is far commoner. We found a Supabase project behind 8,435 of those apps. On 3,680 of them the question "can a stranger read this table" got a usable answer at all, and 2,096 answered yes: at least one table handed rows to a request from outside with no account anywhere in it. In 394 of those the open table was named like a table of people.

Some of that is deliberate. A published menu, a page of listings and a public changelog all live in tables a stranger is meant to read, and our scanner cannot tell those from a table of customers that was opened by accident. It reports what answered and leaves the judgement to you, which is why turning Row Level Security on is not the same as being protected.

If you would rather see your own answer than reason about it, our free scan reads your live site and tells you what it can reach from outside. It takes about 20 seconds and needs no account: scan your app.

How to tell which key you pasted

Read the beginning of the string.

sb_publishable_… belongs in your app. sb_secret_… never does. There is nothing to decode, because what the key is for is written on the front of it.

A long value beginning eyJ is one of the older pair, and that is where the two become hard to tell apart. The middle section of such a key is readable data rather than encryption, and it carries one field that settles the question:

{
  "iss": "supabase",
  "role": "anon",          ← the one that matters
  "iat": 1750000000
}

anon is the publishable one of the pair. service_role is the one to rotate today. Supabase's documentation puts it more bluntly than we would: if a tutorial or an AI assistant tells you to copy a long key beginning eyJ, it was written for the legacy keys.

Both pairs can be live at once, which is the detail that catches people out. Creating a publishable or secret key leaves your anon and service_role keys exactly where they were, and they keep working until you disable them in the dashboard as a separate step. What changed with the newer keys covers that migration, and where each value lives in your dashboard is the page to open if you have never been there.

If the secret key is already in your app

Rotate it before you edit anything, and work in the order Supabase gives.

Create a new secret key in the dashboard. Replace the old one everywhere your project uses it. Confirm every part of your app is on the new key. Only then retire the old one, and the last step differs by which pair you are holding: deleting a secret key cannot be undone, while deactivating a legacy anon and service_role pair is reversible, so you can switch them back on if you find a client you missed.

Whether you rotate first or repair the leak first depends on whether a copy is already public. Rotating a Supabase service_role key walks through both orders and what to read in your logs afterwards.

Keeping it that way after the error is gone

The fix holds until the next prompt or edit that touches your Supabase setup. That prompt can paste a key back in or loosen a rule again, and your app goes on working either way, so the change shows up only when somebody looks.

Reeve Monitor looks for you:

• all nine checks every hour, on up to three apps
• an email the day a re-scan grades your app lower than the one before
• whether the app is up, every 60 seconds
• a monthly report of what it saw

A key that can write every row can also empty every table. Reeve Care keeps a copy of your Supabase database where no key in your app can reach it.

• an encrypted copy every day, kept outside your Supabase account
• each copy verified before it counts, by counting the rows in every table
• a one-click restore that saves what is there now before it replaces anything
• your uploaded files as well, once you connect a Storage credential
• everything Monitor does

What to do today

Start with the one table the error came from, then read the policies on every table you touched the same week. The 10-minute security checklist covers what else tends to be left open in a newly launched app, and the Supabase safety guide goes through the rest of what a stranger can reach.