This is absolutely NOT how you want to handle it. To verify an API key is valid with this method you must leave “API key database” public. Which means anyone can access list of keys. You’d also have to verify the user connected to the key which means users would be partly public which can cause DB dumps by bad actors.
Rather you need to use bubbles recommended way of doing this. Create a backend workflow called /auth no authentication needed. The only step here is “log the user in”. 2 fields passed email & pass
Your API user will pass email/pass to this call and it’ll either deny or accept the server side login.
If accepted it returns a basic auth bearer token you will pass in the header of every other API call. That will authenticate. This also attributes everything to “current user”.
If remember me is checked on login action it’s a 1 yr token. If it’s unchecked it’s 24 hr token expire.
To revoke access you will have a /revoke call with a “log the user out” which expires the key.
This will maintain all privacy rules, authentication, and security of your app.
If you want you can have a second “security” token stored on the user since it’s already authenticated to allow for a bit better attribution of where calls are coming from, logging, or API usage limits. Not necessary though.
Sometimes bubble does expire keys sooner than the expected date so your API user will want to have an error handler that will /auth again if they’re getting an expired token response. However, that’s not all that abnormal.
A lot of other apps (hubspot for example I believe) use this same method. Which is why once a year you get an email from them to login and regenerate your API key. While logged into your dashboard when you click “generate new api key” it actually hits the server to create a new basic auth key which your user then saves but the db only saves the end of the key or an encrypted version of the key. So your /auth call doesn’t technically have to be from the server side by your user.
@code-escapee no work around needed. Do this ^^^ 
I highly recommend anyone who is a serious developer on bubble to sit down and spend a few hours a day for a few days reading the entirety of the bubble manual and test implementing a few things via best practices.
You’d be surprised how many “amazing” bubble developers and even agency developers don’t know some of the basics of bubble docs & best practices.