Skip to content
Oct 12, 2026NewsletterRSS

Brevo Lets Servers Swap API Keys for Tokens That Expire in an Hour

Brevo now lets servers trade a client ID and secret for a token that expires in about an hour, scoped to chosen permissions. API keys keep working.

2 min read

BrevoSending

Hand-drawn illustration of a brass key with an hourglass standing beside a mailbox on a hot pink background

Brevo now lets a backend call its API with a short-lived OAuth token instead of the static api-key header, the company said in its Oct. 6 developer changelog. The flow is the OAuth 2.0 client_credentials grant, which Brevo calls machine-to-machine (M2M). API keys are unaffected and keep working, the entry said.

Tokens last about an hour and carry only the scopes requested

A server posts its client_id and client_secret to https://oauth.brevo.com/realms/partner/oauth/token and gets back a Bearer token valid for about 1 hour, according to Brevo’s M2M guide. There is no refresh token. The server asks for a new one when the old one expires. Calls then send Authorization: Bearer <token> in place of the api-key header.

Brevo’s guide compares the two methods. A leaked API key gives full account access until someone notices and rotates it. A leaked token is bounded to about an hour and to the scopes granted. The guide’s example app asks for contacts:read, contacts:write, crm:read and crm:write.

The Brevo CLI creates and rotates the credentials

Brevo documented new commands for the job. brevo app create --m2m --scopes makes the app, brevo app token fetches a token, brevo app scopes update changes permissions and brevo app secret rotate swaps the secret. Brevo said the old secret keeps working for a grace window after a rotation. M2M apps are private to the organization that creates them.

Brevo’s Oct. 7 changelog entry added that its Quickstart and Getting started pages now point server-to-server integrations to M2M. The Oct. 6 entry said the API key page does the same for new integrations.

The docs list limits on this first version

A token cannot be revoked once issued. Deleting the app or rotating the secret only stops new tokens. Each credential works for one account. And a token requested without an explicit scope currently comes back with every permission the app has, rather than failing.

The take

We think the main gain is a smaller loss when a secret leaks. A static API key works until a person finds the leak and rotates it. A token that expires on its own limits the damage to the next hour, even if nobody notices.

The documented limits keep that gain modest for now. Brevo cannot cancel a token already issued. A leaked secret still buys an attacker up to an hour. The scope default is the more important catch. A team that forgets the scope parameter gets a token as powerful as the old key, with none of the benefit.

Teams on Brevo should move one new backend job to M2M, request only the scopes it needs in every token call, and keep the client secret in a secret manager. Existing integrations can wait for Brevo to close the revocation gap.