You leaked an API key. Here is what to do in the next hour.

Create a new key with the provider and revoke the old one. Once it is revoked, the leaked copy is useless, wherever it ended up. For payment and AI providers, use their dashboard's key management page. For Supabase, create a new secret key in the API keys settings; a leaked legacy service_role key is revoked by deactivating the legacy keys, after the frontend has moved to the publishable key.

Store it as a server-side environment variable on your host, never in a file in the repo and never in a variable with a public prefix. Calls that need it go through a server or edge function.

• Payment provider: look for refunds, payouts or customers you do not recognise.
• AI provider: check usage for spikes since the leak.
• Supabase: look for changed or deleted rows and new users you did not expect.

Tools like git filter-repo can rewrite history to remove the key, but anyone who already cloned the repo keeps a copy. Rewriting is tidy; rotating is what actually protects you.

Usually a builder pasted the key to get past an error, or a variable got a public prefix. Tell your builder to read the key from a server-side environment variable, and scan again to make sure nothing else slipped in.