Good question, thanks. You are right, in case CloudRail goes down no one will maintain the libraries anymore. Despite the fact that we won't go down :), you have to ask yourself if the risk is really that big? The service definitely saves you time now and for the next X years. How many time would you invest during that period with native integrations? Definitely one by one SDKs to integrate and I bet some of them need to be replaced as well. E.g. Dropbox from v1 to v2 was a complete new API and SDK. I think integrations need to be maintained anyway and in the worst case (CloudRail goes down) you have to invest max the same time compared to manual. We love open source and this is an option as well.

1) What APIs has your team built before that qualifies them to build this?

Our team has been in the API business for 4 years now with a lot of different projects and products.

2) How will you manage changes, bugs, and obscure documentation issues in the APIs that will be made available through you?

We have a system called API Change Management. Every connected API is monitored for changes. Once something happens or is announced we update our SDKs and put that information back in the system. Afterwards the system checks all SDKs which are implemented by customers and which integrations they use and automatically notify affected ones by email and via our portal. .. 4) What language will the API be written in?

Currently we support Node.js, Android, Java and iOS (Swift & Objective-C)

5) Regarding API access security: How will you handle access to multiple APIs for the same client when each API requires a different set of tokens?

We let customers use their own API credentials which they get directly from the providers.