Introduction

The Criteo API enables the creation of custom apps to help advertisers grow their businesses. Whether you're a brand, agency, retailer, or third-party partner, the Criteo API offers various authentication methods to suit your application's needs.

To get started, your users must delegate permissions for one or more Criteo advertisers they oversee for your application to function.

Criteo supports OAuth client credentials and authorization code grant types. This guide explains the benefits of each grant type, helping you choose the best option for your application.

📘

This guide assumes you have a developer account and your application has access to an organization within Criteo. Instructions for getting started are available on our onboarding checklist .

---

OAuth 2.0 Grant Types

Criteo provides OAuth client credentials and authorization code grant types.

---

Client Credentials

The client credentials grant type is designed for straightforward API connections and apps that are authorized to access a few advertiser accounts. This method authenticates the client (the application or service) rather than an end-user, making it ideal for server-to-server interactions.

Client credentials are specific to each application or service, allowing resources to be isolated across different apps. Each app can have its client credentials and associated permissions, making this a suitable option if you plan to manage multiple applications with varying permissions.

• Case scenarios: This workflow is ideal when the data owner and the application developer are the same, or when there is only a single data owner. It does not segregate data based on the accessed account.

For more information, check out the app setup process for OAuth App - Client Credentials Setup.

---

Authorization Code

The authorization code grant type involves obtaining an authorization code, which is then exchanged for an access token. This method is used when an app needs to access a user’s (resource owner’s) resources and perform actions on their behalf.

The app starts the process by redirecting the user to the authorization server’s login page. After successful authentication, the user is redirected back to the app with an authorization code. The app then exchanges this code for an access token and a refresh token, enabling access to user-specific resources.

While the authorization code grant type may involve additional steps, particularly in managing the authorization code and token exchange, it is well-suited for scenarios requiring user consent and interaction.

• Case scenarios: This workflow is appropriate when the application manages data for multiple data owners, as it segregates data behind separate access tokens. The consent process ensures data is bundled by each consent granter.

For setup details, refer to OAuth App - Authorization Code Setup