I haven’t looked at that in depth but I believe it automatically makes API endpoints available based on the database schema. I’m not sure how access is limited.
With the WebAPIBridge the calling account only has EXECUTE privileges and authentication and authorization is (expected to be) handled in the database, ie, a sessionid is passed as a parameter. Only procedures with a comment of EXPORT are made available.
Access to tables/procedures is limited by the role assigned by the token (or a default role). Access to data/rows is limited by RLS (row level security), which is built into postgresql and limits what rows are visible to each query.
You can pretty much make it as locked down or as open as you want.
One thing that is great about RLS is you don't need to think about the authZ when writing the query since the policy on the table restricts what is visible to the current authorized user.
If you are building a product in a similar space I'd recommend you take a look.
With the WebAPIBridge the calling account only has EXECUTE privileges and authentication and authorization is (expected to be) handled in the database, ie, a sessionid is passed as a parameter. Only procedures with a comment of EXPORT are made available.