Hi community - I have been looking for answers to this topic, but haven’t found any guidance. I want to open up a few tables to third-party developers, and I want only certain fields to be discoverable through the Data API. The solution might be privacy rules, but how would I set this up if I need the fields for the application to run?
You can do it with privacy policy to that table, and just open the data api for the table. Any thing allowed by privacy poly to everyone will be visible. Just open the data api to browser or call it with a get call.
If you still stuck, ping on LinkedIn or WhatsApp love to help, or schedule a free consultation from my profile.
1 Like
Thank you for your response, I just sent you a LinkedIn invite. It’s still unclear how I only hide certain fields from the API to ensure none of the privacy rules impact the rest of my application.
You can’t. In normal web dev you could provide an api key with a certain scope but such a thing isnt possible natively in bubble.
You could construct a custom endpoint that only returns the data you want. But if the third party has that api key they can access it regardless because you cant delineate such restrictions in bubble
2 Likes
I really hate the lack of scopes in Bubble.
There is some nuances to the API connector and options.
Obviously you don’t want to give your API users an Admin token - that gives full read access to any exposed Data API points. (just to get that off the table)
Your Data API Users can use a username and password - you need to create an authentication end point (its just a public API endpoint you create that returns an authentication token. (search the forum for how to do that)
Then having got an authentication token from the authentication endpoint - your users can authenticate to the Data API with that token, and critically - Privacy Rules for that user will apply. ie design your privacy rules to expose data as per your requirements. Optionally you could have separate user accounts for API users vs “Web UI” users if that suited your design better.
Another option is to use a public Backend workflow that returned the data.
The pros of this design is that you have full control on what the API looks like, and you could add , throttling, observability, logging etc. You also decouple the database from the API - meaning you can change the API and Database independently from each other.
The cons are you might have to implement pagination, and you have to come up with your own API design.
Good luck 
1 Like
Thank you. This is also what @Baloshi69 suggested when we had a call. Will then ignore the Data API and try building custom endpoints with the Workflow API. Unfortunately way more complex than I was hoping it to be