1) Did I understand this correctly, oversimplifying, instead of going api.slack.com/users I go nango.com/slack/users
If I did it leads to question 2) since I assume this won't have feature parity 100% of the times, what's my escape hatch when I need a feature that's available in an api and not in your service, if worse comes to worse, can I still easily access the original api easily?
2) You can write your own integration scripts, in code, consuming any endpoint from the external API, so you are not limited to what Nango pre-builds (details: https://docs.nango.dev/understand/concepts/scripts).
But you can also access the original API through the proxy, which will inject credentials, log requests, help you with pagination (details: https://docs.nango.dev/understand/concepts/proxy).
So to recap:
1) Nango supplies easier-use-to-use wrappers over a host of common APIs, making the most common operations simpler. Nango generally handles auth, logging, pagination.
2) Nango is extensible through custom scripts when your use case falls outside the common ones.
Question 1) Nango provides some consistency to the APIs in its wrapper so, to some extent, you are learning the "nango way" vs hundreds of bespoke ways?
Question 2) How do you handle API churn with hundreds of APIs supported? On any given day, there's got to be a decent chance of something changing that breaks you?