The account provisioning APIs allow you to programmatically create apps on behalf of your customers, or to provide them with scoped credentials to manage their own set of apps. If you need to embed messaging capabilities in your software, and offer those capabilities to your different customers in an automated way, the account provisioning APIs are there to help you achieve that goal.
With the account provisioning API, you can provide messaging as a core feature of your software product - without necessarily revealing to your customers that you’re using to power delivery of those messages. This allows you to benefit from the power of to build innovative products and features. Here are some examples of how a few different types of software makers are using account provisioning today:
An app represents a customer or business as a whole using your software, or a department within one of those customers or businesses. An app contains a set of configured channels as well as any associated appUser profile and conversation data. Each app’s appUser and conversation data exists separately; apps never share data between each other.
There are two typical ways to use the account provisioning API:
See creating and managing apps for more information.
A service account represents an API consumer, with its own set of credentials, that only has access to a certain subset of apps. For software makers that create apps on behalf of separate customers or businesses, service accounts can be used to generate and distribute credentials that only have access to a single business’ data.
For example, let’s say your company provides on-premise software, with no centralized cloud-based server. Your software, once deployed, allows a business to create as many apps as they want, in order to segment their appUsers based on some criteria (based on geographic location, across their different product offerings, per language, etc.).
In order to enable your deployment to authenticate with the API, you will need to distribute credentials to each of these on-premise deployments. But, you should not distribute credentials associated with your user account API keys, because separate deployments would not be isolated to their own data. They could manage each others’ data.
Instead, with your software you should:
With these credentials, your customers will be able to call the API and create apps. Even though the apps ultimately exist under your user account, and fall under your own billing plan, each deployment would have access to manage their own apps, but are prevented from accessing those of other deployments.
See using service accounts for more information.
To get started with the account provisioning API, you’ll need to generate a user account API Key from the dashboard’s account page and use it to authorize your calls to the API.
See the authentication overview for how to use an API key to authenticate API requests.
See the account provisioning API reference for the list of available API methods.
You can use the account provisioning APIs on any pricing plan with API access. On certain plans, the number of apps you can create is capped, but you are still able to build, prototype and test your product.
If you’re building software on and want to create a number of apps, contact us to tell us about what you’re building and talk to sales about pricing options.