The Smooch 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 Smooch to power delivery of those messages. This allows you to benefit from the power of Smooch 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 Smooch 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 Smooch API, you will need to distribute credentials to each of these on-premise deployments. But, you should not distribute a JWT signed with your user account keys, because that credential would allow separate deployments to manage each others’ data.
Instead, with your software you should:
With these credentials, your customers will be able to call the Smooch API and create Smooch apps. Even though the apps ultimately exist under your Smooch 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 Secret Key and use it to authorize your calls to the API.
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 Smooch 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.