Provisioning Kloudless projects dynamically for each customer Vinod Chandru Published: January 24, 2019 One of the first tasks a new Kloudless developer must step through is to create a Kloudless project, also known as a “Kloudless Application.” This is a container that holds all of the configuration required to customize an integration’s appearance, behavior, authorization credentials, and more.A common pattern is to create a project for development and a couple of others for staging and production environments. This way, each environment has its own set of secrets, and more importantly, distinct third-party OAuth credentials.However, there are scenarios where grouping configuration options per environment isn’t granular enough; your application may need to vary configuration for each customer’s cloud accounts instead. This could be for a number of reasons:Stricter data isolation and access guaranteesDeploying the application to each end-customer’s environmentPer-customer white-labeling: custom logos, OAuth credentials, redirect domain names, and moreArchitectures that favor per-project tokens (“API Keys”) to access all of an individual customer’s accounts rather than individual Bearer tokens. Note: the Bearer token should still be verified server-side during the authorization flow as a precaution.A straight-forward solution is to create a Kloudless project per customer. Below, we’ll discuss how to do this programmatically.Create projects with the Meta APITo begin, create a new Kloudless Application via the developer portal to use as a template for each customer’s Application. Configure the right OAuth keys, name, description, logo, and any other settings you’d like. Then, obtain a Meta Bearer Token via your Account Settings page to use with the Meta API.When you’d like to provision a Kloudless Application for a user/customer, use the Application Creation endpoint with the source set to the ID of the Application created previously as shown below. This will create a duplicate copy of the Application with a new ID and updated values. It will also duplicate all related objects nested under that project such as OAuth keys, Redirect URIs, and Event configuration. curl -H 'Authorization: Bearer S4i5EG5ViEAVmMaCilB5' \ -H 'Content-Type: application/json' \ -d '{"name": "Test App 2", "source": "wSPk9y5D7p5o87k0ACGKxR"}' \ 'https://api.kloudless.com/v1/meta/applications/'1234curl -H 'Authorization: Bearer S4i5EG5ViEAVmMaCilB5' \ -H 'Content-Type: application/json' \ -d '{"name": "Test App 2", "source": "wSPk9y5D7p5o87k0ACGKxR"}' \ 'https://api.kloudless.com/v1/meta/applications/'Associate user data with an individual Kloudless AppUse the new App ID returned in the previous request when prompting users to connect cloud accounts via the OAuth 2.0 flow. Ensure the user is logged in to your application during this process to correctly associate them with the Kloudless Account ID returned at the end of the authentication flow.The user’s accounts can now be accessed via either Bearer Tokens or the Kloudless project’s app-wide API Key. The API Key grants access to all accounts connected to the Kloudless Application, and can be safely used on the server-side in this scenario. It can also be used with the Token Exchange endpoint to generate Bearer Tokens with narrower scopes, such as to a specific account. This is helpful if you would like to dynamically generate tokens for use on the client-side, for example.Further isolation guaranteesThe process above ensures a degree of separation between the different users connecting accounts to your Kloudless project.Another way to further isolate customer data is to use separate Kloudless Docker containers. Please reach out to us at hello@kloudless.com if you’d like any further information on this approach or our multi-tenant cloud.