We offer 2 forms of authentication for apps:

  • OAuth
  • No authentication

Deciding which is right for your app depends on whether you are accessing the Kit API or whether you require authentication to tie a Kit account with an external account for your service. Though we do offer API keys to access the V4 API, these should only be used for testing purposes, with OAuth required for the app to go live.

Though keys offer a quick method of testing the API before finalising your app, some endpoints - such as the Create purchase or Bulk... endpoints - require OAuth authentication, so will not be able to be tested this way. Specific authentication requirements can be found for each endpoint in the API documentation.

The only time OAuth is not required would be for apps that only offer plugin functionality that rely on publically available endpoints that require no authentication. A great example of this would by the Kit GIPHY app, that requires no authorization from the creator for Kit to access GIPHY’s library of images.

​
Full app authentication flow

The authentication flow varies based on whether your app offers API access, plugin access or both. To learn about these flows in depth, visit the API authentication and plugin authentication pages, which will help guide you through the requirements and share examples to help you get up and running.

The below diagram and step-by-step outline will describe the full flow when you have both API and plugin access configured for your app. If you are looking to build an app with just API or plugin access, visit the specific API authentication and plugin authentication pages.

1

Creator installs your app

Authentication begins with the creator installing your app from the Kit App Store or your app’s details page. They can click the “Install” button on either page.

If you want to start this flow from your site as well, link your user to your app’s details page, appended with k_app_id=k_{app_id} (which allows us to attribute sign-ups to your particular app). To find your app id - click the “Preview” button for the app on the Bulid tab of the Kit App Store and the id will be found in the URL path app.kit.com/apps/{app_id}.

For example, for the GIPHY app, you would send your users to https://app.kit.com/apps/717?k_app_id=k_717

2

Redirect to plugin authorization flow

The creator is then sent to your service’s OAuth flow, whereby the creator grants Kit access to your platform, in order to retrive the data needed for your plugin(s). Here, Kit will use the OAuth endpoints served by your authentication server to request access tokens, that will be used to authenticate all future requests to your platform.

3

API authentication

Once plugin access is completed, API authenication begins, with Kit kicking off the flow by making a GET request to the authorization URL you have set up for your app.

It is important that at this stage, you store the redirect property that is appended to the GET request, as this will be the URL your app will need to redirect to once the Oauth flow is completed
Once the creator gives authorization for your service to access the Kit API on your behalf, your app will request an access and refresh token that will be used for all future app calls to the API.

4

Redirect the user to complete the installation

Once API authentication is completed, redirect the user back to the redirect, URL provided as a query paramter in the initial authorization request. This will ensure the installation flow is tracked and completed properly. This property currently sends users back to your app’s details page, which will help guide them through using and getting the most out of your app they have just added to their creator kit.

If you have set up the Redirect URL after install field in your app’s settings, a modal prompting creators to continue their journey on your configured site will appear at this point. See this section in the app details page guide for more details.

5

Ongoing refresh token flow

With installation now complete, both Kit and your service will continue to refresh access tokens as required; using the refresh token shared in the same response as the access token to request an updated access token, when the current one has expired.