Self client type overview

The authorization code flow requires user intervention for giving permissions for an application to access Bigin resources. On the other hand, when you want to call Bigin APIs from stand-alone applications or web applications that do not need user mediation for authorization, you cannot use the authorization code flow. In that case, you can register your stand-alone or web application as a self client with the API console to get client credentials, and then generate your registered client's authorization code from the API console itself. Further, you can exchange the authorization code for access tokens by authenticating your application with client credentials.

For example, when you want to submit your application's server-side data to Bigin or synchronize records between your application and Bigin, use the Self Client type while registering the application with the API console as it does not require the user granting permissions.

Also, whenever you want to get started with Bigin APIs, you can often experiment with APIs using your own Bigin account and by registering the self client type with the API console. This is helpful in testing our APIs before jumping into the complexities of getting other user permissions.

The steps below describe the authorization process for self client type, where an access token is generated, and then used in an API request:

  1. As a prerequisite, register your application as self client with the authorization server to get client credentials such as client ID and client secret. The domain and redirect URL are not required for registering self client type.
  2. In the first step, from the API console, generate an authorization code that is accessible only within the specified time duration.
  3. Once you receive the authorization code, in the second step, you must request access tokens in exchange for an authorization code.
  4. Your application receives access and refresh tokens. In the third step, you can send an API request using the access token for accessing resources.
  5. The access token is a short-lived key that needs to be refreshed. In the fourth step, you can use the refresh token to generate a new access token.
  6. In the last step. you can revoke your refresh token that invalidates your application to access resources. This step is optional and can only be performed when the key tokens are compromised.