@LB
I’ll take a stab at a few of these.
3: The app has an API key with a set of default privileges (which could be none). When a user logs in, the app/user combination gets a set of privileges. User names can be used to emulate row-level security.
4: I think it’s reasonable to publish the auto-generated docs for each endpoint separately once the schema is stabilized. This will also improve performance. In other words, each endpoint’s docs could be saved to a static html page somewhere on your website.
5: I haven’t had to touch sessions and tokens, but I’m using AD not OAuth, so there might be a difference.
6: Use a proxy or mod-rewrite; I haven’t seen a way to change endpoints. This dovetails with your other question about not needing an API key. If you’re using mod-rewrite or a proxy, I’d go with a structure like api.example.com/payments since you won’t be tied to DF’s url structure at all.
7: I haven’t tried doing these integrations; they might require some custom code to translate the API calls.
8: DF allows you to write custom code in PHP, Python, or JS, so I don’t foresee an issue here. https://wiki.dreamfactory.com/DreamFactory/Tutorials/Server_Side_Scripting
9: DF allows you to use Relationships which do what you want. https://wiki.dreamfactory.com/DreamFactory/Features/Database/Related_Data
10: This seems possible depending on the complexity of the request. If you’re open to server side scripting, you should be able to also specify a lookup table with “who can see what”. How to implement data access based on a table with user’s permissions
HTH!