We just launched a new authentication option for API workflows that gives you more control over who can trigger them. You can now set API workflows to run with admin-only authentication, adding an extra layer of security for sensitive operations.
What’s new
You can now restrict API workflows to admin only access, meaning only users with admin-level API keys can trigger them.
We’ve also updated the interface. The previous This workflow can be run without authentication checkbox is now a clearer authentication dropdown with three options:
None required: Any user can trigger the workflow (use for signup/login flows).
User and admin: Any authenticated user can run the workflow. To control which specific users should be able to run the workflow, you’ll need to set up the correct logic using conditions and/or privacy rules.
[New] Admin only: Only users with admin-level API keys can run the workflow.
The new dropdown is fully backward compatible — your existing API workflows will continue working exactly as before.
What this update means for your builds
This improvement makes your API workflows more secure by giving you more granular control over access. With the admin-only option, you can protect sensitive workflows from unauthorized or unintended access, especially useful for administrative functions, data management operations, or other workflows that should only be accessible to trusted users with elevated permissions.
Where to find the new feature
You can find the new authentication dropdown in the property editor when you select any API workflow. The setting is available immediately for most users and will roll out to all other users shortly.
Give it a try and share your thoughts and any questions in the thread.
In line with this update, here are a couple of updates which should be extremely high priority, listed in order of ease of implementation.
Add an “Allow access to private files” option. The median Bubble app built in 2026 will necessitate uploading files to LLMs or other 3rd party services for analysis/etc. Right now the only way to allow these third parties access is to use a Bubble API token which, if compromised, would be a complete security disaster for your app.
Related to point #1, please allow better scoping of Bubble API tokens. In the same way that Privacy Rules are not “all or nothing” (they have checkboxes for search, files, autobinding, etc.), Bubble API tokens should have granular controls for read/write/etc and specific Things/Fields. Ideally, each user would have their own Bubble API token, so if a token gets compromised, only that user’s data is ever affected. But at the very least the tokens should be scoped.
This will save many public API workflows that before could be run by any user, but now only admin keys will be able to run them (even though in most cases the privacy rules were already enough, it was still bad). And it also removes extra work we sometimes had to do to create additional protections, like an api-key parameter where the workflow would only run if it was provided.
Task of the day: switch public endpoints to “Only Admin”
It’s not that the user is an admin. Instead of being a token from any user, that API workflow will only accept the admin token. Those are the tokens you can generate in the API section — the Admin API Tokens — like in the screenshot above.
You will use them in your external service requests or in the API connector. Such as the call authorization.
The authentication options are irrelevant when the workflow isn’t public (scheduled workflows ignore authentication because you control permissions by schedule action or workflow conditions), so the team has now hidden those options when the workflow isn’t public.
Note to self: It is still useful to capture the headers of the call and to match against the incoming Bearer token to ensure the correct token is being used.
