Existing app broke AGAIN because FlutterFlow changes the rules overnight.

I honestly cannot believe this is happening again.

FlutterFlow pushed another sudden change and now an existing production app that was working perfectly shows 12 hard errors for “Exposed API Credential”.

I changed nothing. My backend changed nothing. FlutterFlow changed.

And now, out of nowhere, I’m potentially unable to build my production app until I change an integration that has been working for months.

And to make this even more ridiculous: these calls use the Supabase anon/public key. This is NOT a service role key and NOT a secret credential. Supabase explicitly expects the anon/public key to be used client-side. Security is handled through the authenticated user JWT, RLS, and backend permissions.

Yet FlutterFlow suddenly decides this is a hard project error.

HOW CAN THIS KEEP HAPPENING?

Breaking changes like this cannot just appear overnight in a platform that people use for production apps.

A warning? Fine.
A migration notice? Fine.
A proper migration path? Absolutely.

But suddenly turning a previously valid production configuration into hard errors?

THIS CAN’T BE TRUE.

Who is making these decisions without considering existing production projects?

This is exactly the problem I keep having with FlutterFlow: something works, a platform update happens, and suddenly developers are forced to repair something they never broke.

FlutterFlow needs to stop introducing breaking validation changes without:

advance notice
backwards compatibility
a migration path
or at least an override for legitimate configurations

Production development platforms need stability.

Existing apps cannot randomly become broken because FlutterFlow changes the rules overnight.

I have already verified that the affected API calls only contain the standard Supabase anon/public key, not a service role key or any secret credential.

These API calls have been working in the production app for a long time without any issues. I have not changed the API configuration, the Supabase backend, or these credentials.

The errors only appeared after the latest FlutterFlow changes/update.

I also checked FlutterFlow’s current guidance around private API calls and environment values, but converting these calls to private/server-side calls would unnecessarily change the architecture of a working production app. A Supabase anon key is explicitly intended for client-side use.

At this point I am looking for the official FlutterFlow solution for using a legitimate Supabase anon/public key in custom API calls without receiving hard “Exposed API Credential” errors.