In cases where you are building an integration with ZoomInfo and all you care about is transmitting data between your servers and ZoomInfo without needing each user to sign in, then you should use the Client Credentials Flow. In this flow, the applications exchanges its client credentials (client_id and client_secret) for an access token. This flow eliminates the need for user interaction but it does require you to select an integration user that will be used to attribute all actions performed by this application.

The Client Credentials Flow is a common flow for applications where tracking data consumption or data attribution for each user is not necessary. The use cases for Client Credentials Flow applications can range from:

• Data Syncing - You have an internal service that runs in the background and you utilize this to run regular syncs of ZoomInfo data to constantly enrich and freshen your sales data
• Integrations with In-House Applications - This use case can fall here or with the Authorization Code Flow with PKCE, but in cases where you want to integrate ZoomInfo functionality into an internal application and you don't care whether the data is attributed on a per-user basis, then this flow can enable all users of your in-house application to utilize ZoomInfo data for their purposes

Because there is no need for user interaction, Client Credentials Flow applications do require approval from ZoomInfo before they can be used. As part of the submission process, you will provide a description of the use cases that this application will enable you to solve. While your app is under review, you will still be able to utilize it for development in a trial period of 2 weeks

Generate an Access Token

For Client Credentials Flow applications, there is a single step needed to generate access tokens

1. Exchange Client Credentials for Access Token

Exchange Client Credentials for Access Token

In Client Credentials Flow applications, since the application is acting on-behalf-of itself and not any other user, there is no need for user interaction. The application simply exchanges its credentials for the access token directly.

This request contains the client_id and client_secret that are used to identify and verify that the external client. There are two ways to provide the credentials to the token endpoint: HTTP Basic Authentication Scheme or Request Body Parameters. The HTTP Basic Authentication Scheme is the recommended method for providing client identification. If the Authorization header is provided, any client identification provided in the request body will be ignored.

POST https://api.zoominfo.com/gtm/oauth/v1/token
Authorization: Basic *********************************
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=client_credentials

POST https://api.zoominfo.com/gtm/oauth/v1/token
Content-Type: application/x-www-form-urlencoded
Accept: application/json
grant_type=authorization_code&
code=vKkAtlDe50fRP7pUPJQ6RIrpXx1PmwAzW19tT4RUit8&
code_verifier=QC5zAPqWtytPwzo21qeajWDDpoxcRGA_gbALA7ZtFtU&
redirect_uri=https%3A%2F%2Fwww.example.com%2Foauth%2Fcallback&
client_id=0oaf6t3osgvaPvy4E1d7&
client_secret=***************************

The following parameters are required for each token exchange request

The following parameters are optional for each token exchange request

Upon successful verification of the external client's credentials, ZoomInfo's authorization server will respond with the access token. The response will always be encoded in the application/json content type.

{
  "access_token": "eyJraWQiOiJKdThxUW1tTUx1SG9QSEFVQlJnUmh...jnIn951t3kLf6VZ6SOsYKSVY9kGeNbCGkufCNLQ",
  "expires_in": 1000,
  "scope": "api:data:company api:data:contact api:audience:read...",
  "token_type": "Bearer"
}