Authenticate with Client Credentials

Use Client Credentials for server-to-server integrations with no end user, such as cron jobs, exports, and backends. Your application authenticates as itself with its client_id and client_secret, with no user interaction.

Note: This is not the same as API keys in the Vibe ad platform. That separate, legacy mechanism is being deprecated. Developer Platform credentials are issued by your app in the Developer tool. If you are migrating, see Migration Guide from API Key.

If a Vibe user signs in to your app and grants it access to their account, use Authenticate with OAuth 2.0 Authorization Code instead.

Create a Client Credentials app

1. In the Vibe Developer tool, create an app and select API Key as the authentication method.
2. Select only the scopes your server-side workflow requires.
3. After app creation, copy the client_id and client_secret. Store the secret only on your server; it is required for the token request below.

For Marketplace requirements—including app information, required listing content, support materials, scope review, and submission—see Submit your app for review and Marketplace listing.

Optional: Support public app installations

When an advertiser installs your public app from the Marketplace, they receive credentials for their account. Your app acts as a template: the credentials inherit the scopes you selected during app configuration. Choose those scopes carefully because each installation receives that same permission set.

This lets partners whose platforms do not support OAuth redirects support multiple advertiser accounts: each advertiser installs the app and provides their generated credentials to the partner.

Base URL

All OAuth endpoints are available at:

https://api.vibe.co

Client Credentials Flow

Use this flow when your application needs access to its own resources, with no user involved. There is no redirect and no consent screen — your server requests a token directly from the token endpoint.

Step 1 — Request a token

Make a server-side POST request to the token endpoint. Never make this request from client-side code, as it requires your client secret.

POST https://api.vibe.co/oauth2/token
Content-Type: application/x-www-form-urlencoded
Authorization: Basic <BASE64(YOUR_CLIENT_ID:YOUR_CLIENT_SECRET)>

grant_type=client_credentials
&scope=campaigns:read

The Authorization header value is Basic followed by the Base64 encoding of <client_id>:<client_secret>.

Example request:

curl -sX POST https://api.vibe.co/oauth2/token \
  -u "$CLIENT_ID:$CLIENT_SECRET" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "scope=campaigns:read"

Example response:

{
  "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
  "token_type": "Bearer",
  "expires_in": 3600
}

The Client Credentials flow does not issue a refresh_token. The access token expires after 1 hour.

Step 2 — Call the API

Include the access token as a Bearer token in the Authorization header of every API request:

GET https://api.vibe.co/*
Authorization: Bearer <ACCESS_TOKEN>

Token Response Reference

Access tokens are JWTs. You can inspect the payload by Base64-decoding the middle segment (between the two . characters). The payload contains standard claims such as sub, scope, iat, and exp. Do not rely on the token payload structure in your integration logic — use the API responses instead.

Token Renewal

Client Credentials tokens cannot be refreshed — there is no refresh_token. When an access token expires (after the duration indicated by expires_in), request a new one from the token endpoint exactly as in Step 1. Request a new token when the current one expires, or shortly before, rather than requesting one per API call.

Error Reference

Errors from the token endpoint follow OAuth 2.0 standard error codes.

Error responses from the token endpoint are JSON:

{
  "error": "invalid_client",
  "error_description": "Client authentication failed."
}