I am really stomped with this one. I want to be able to hide certain fields from an API end point. I know i can return a single field but in this case i want to be able to return all the fields except the ones in red. Is there an option to hide/show fields in results returned? So at the end i will only have _id & title field!
I see what you mean (I hope i understood it right). But what i am trying to do is create an app that serves vehicle makes, models to not only users but to servers and other 3rd party websites that need to use my database. Something like an API on subscription, will that work with the below?
From what i understand (from the below documentation) is that the user has to pass his email and password as parameters to login. Is that correct? Will they need to call one API to login and another to fetch data or can they do it in one API call?
- Create sign up / login api workflows. This is useful for building an alternative front-end to your Bubble app, such as a native app that you develop. When an API workflow contains a sign up or a login action, a user ID, a token and an expiration (in seconds) are returned with the response of the call. Subsequent calls to your app's API, with a header "Authorization: Bearer API_TOKEN" will runs all calls and workflows in the context of the user associated with the token. This user will be the 'Current user' you can access in your actions, etc. Privacy rules will apply to this user as they would if the user was logging in the Bubble app and using it in her own browser. This token should be kept safely wherever you're using it.
At the end of the day, you need a way to authenticate who is calling your API (or you don’t, in which case they can make calls without a key, up to you), In general it’s better to have the use a key.
Hmm got it. I can make it work like that. I guess that if there is a way to enable the user to create there own API tokens (to be made available under the API settings tab) then we can have another way of tracking these unique API back to the user who called them.
But that’s a discussion for another time. I guess the issue is whether the user will be able to surrender his password to be used as a parameter in the API call is what’s going to create an issue.
Thanks for input it’s been great. I believe I speak for everyone here by saying we believe in bubble, it’s mission and vision and the awesome support.