Changelog

With Brevo CLI 2.5.0, you can create public apps: OAuth apps that any Brevo account can authorize once Brevo has reviewed and approved them. Use a public app when you offer a Brevo integration to your own customers, for example with an install link in your SaaS product or a listing on a third-party marketplace. Brevo doesn’t list public apps on a Brevo marketplace. Private apps are unchanged and remain limited to your own organization.

New endpoint POST /wallet/passes/{installationId}/redeem records that a contact’s wallet pass was scanned or redeemed, for example a store visit, event check-in or loyalty check-in. The scan is recorded as an event that can trigger automations and update contact segments.

The request body is optional. You can include location, amountSpent, eventTag and customData to describe the scan. If Wallet isn’t enabled for the account, the endpoint returns 422 with the code WALLET_NOT_ENABLED.

POST /contacts/export now documents what happens when no contact matches the filter: no export process is created, and the endpoint returns 200 with an empty object instead of 202 with a processId. Treat that response as “nothing to export” rather than a failure, and don’t assume processId is always present.

Endpoint reference: Export contacts

POST /contacts/export now supports date filtering through customContactFilter, so you can export only the contacts that changed within a time window instead of pulling the full set and filtering client-side.

New filter fields (used with actionForContacts):

• modifiedSince — export only the contacts modified after this date-time.
• createdSince — export only the contacts created after this date-time.

Improved

• Machine-to-machine (M2M) authentication — The client_credentials token endpoint is now https://api.brevo.com/realms/partner/oauth/token, on the same host as the API. The previous URL, https://oauth.brevo.com/realms/partner/oauth/token, keeps working. The guide’s token example now requests an explicit scope and explains that requesting a scope the app wasn’t granted returns 400 invalid_scope.
• API reference — The OAuth 2.0 token URL in the API reference points to the new endpoint.

• Added the Brevo Developer Terms page, linked from the site footer. The terms govern your use of the Developer Tools and the Distributable Apps you build with them.
• Added a site-wide footer with links to the Brevo Anti-Spam policy, Privacy policy, User agreement, Legal Notice and Developer Terms.

Added

• Integrations — Six new guides under Messaging API > Integrations show how to send email through Brevo from popular app builders and automation tools: Base44, Bolt.new, Lovable, n8n, v0, and Supabase Auth emails over SMTP. The Supabase guide is also linked from SMTP relay integration.

Improved

Added

• Machine-to-machine (M2M) authentication — New guide for authenticating server-to-server calls with the OAuth 2.0 client_credentials grant. Create an M2M app with the Brevo CLI, exchange its client_id and client_secret at https://oauth.brevo.com/realms/partner/oauth/token for a short-lived access token (about 1 hour, no refresh token), then call the API with Authorization: Bearer <token> instead of the api-key header. API keys are unaffected and keep working.
• API reference authentication — The API reference now lists OAuth 2.0 alongside API key as an authentication option. See Authentication schemes.
• CLI reference — Documented the M2M commands: brevo app create --m2m --scopes, brevo app list --type m2m, brevo app token, brevo app secret rotate, and brevo app scopes update. These commands require a Brevo CLI release that includes Machine-to-machine support.

Breaking changes

• Begin transaction / Cancel transaction / Complete transaction — The transaction status enum values pending and complete were renamed to draft and completed (rejected, cancelled, and expired are unchanged). Code that checks for the old string values must be updated.

Added

Added

• Get subscription info (GET /loyalty/config/programs/{pid}/account-info) — Response now includes loyaltyProgramName, a membership object (loyaltySubscriptionId, createdAt, updatedAt) resolved from the provided contactId or loyaltySubscriptionId, and new reward fields: publicDescription, unit (currency code or PERCENT), and value (the reward’s value snapshot at attribution time). Also adds balanceDefinitionName, rewardName, groupName, and tierName alongside their respective IDs. See Get subscription info.

New endpoint GET /v3/objects/{object_type}/associated-records returns the records associated with a single source record. Associations of every type come back together in one paginated list, most recently created association first.

• Identify the source record with exactly one of id, ext_id, email or sms. email and sms are only accepted when object_type is contact.
• Filter the response with type, up to 5 associated object types per call, for example ?type=contact&type=garage.
• Results are returned 20 per page. Increase offset by 20 until has_more is false.
• Contacts in the response carry all of their attributes, with attribute keys in lowercase.

Push app-config.json to Brevo with brevo app upload. It fetches your app’s current state, shows a local-vs-server diff, and asks you to confirm before pushing anything. No differences means no network call.

• Edit the field you want to change in app-config.json — name, redirect URLs, scopes, logo — then run brevo app upload. The old --name, --redirect-uri, --scope, --logo-uri, and --app-id flags are gone.
• app-config.json also has a cleaner shape: auth.redirectUrls is now auth.redirectUris, distribution is now distribution_type, and there’s a new read-only version. Existing files keep working and migrate automatically the next time a command writes them.
• brevo app update still runs, but only to point you to brevo app upload — it no longer changes anything.

Lost your project folder, or setting up on a new machine? brevo app scaffold --app-id <id> sets an empty directory up for an app you already have, picking up where brevo app update --app-id left off. Leave off the ID and it offers to pick from your apps interactively.

brevo app create now writes your app’s base project first, then asks “Scaffold the Test OAuth App?”. Decline to stay base-only and add the OAuth test server later with brevo app scaffold. Non-interactive runs always stay base-only.

The Import your products guide now documents the alternativePrice (float) field: a secondary price displayed alongside the main price, typically a discounted or sale price, a member price, or a compare-at price.

Added alternativePrice to the request examples and parameter tables for Create or update a product and Create products in a batch.

Added a “Passing an external identifier (EXT_ID)” section to the JS tracker’s identify() guide showing how to pass EXT_ID as an attribute alongside email_id. The same pattern applies to SMS, WHATSAPP, and LANDLINE_NUMBER.

Guide updated:

Identify users (JS)

We clarified the description of the per-recipient contactPixelTrackingConsent field on the transactional send-email endpoint to accurately reflect how it behaves:

• contactPixelTrackingConsent: true — recipient has consented; the open pixel identifies them.
• contactPixelTrackingConsent: false — the open event is anonymized (counted in aggregate statistics only).
• If the field is not passed, the recipient is treated as unknown consent status and the email is still sent — the open is anonymized unless your account is configured to track unknown-consent contacts. A value other than true/false is rejected. The field is ignored entirely when the feature is not enabled for your account.

You can now customize UTM tracking parameters for email campaigns. When creating or updating a campaign, pass optional utmCampaign, utmContent, and utmTerm fields to override default values that appear in outgoing tracking links.

Request fields (optional):

• utmCampaign — Customize the utm_campaign value. If empty, the campaign name is used. Only alphanumeric characters and spaces are allowed.
• utmContent — Customize the utm_content value. Appears on outgoing tracking links alongside utm_campaign.
• utmTerm — Customize the utm_term value. Appears on outgoing tracking links alongside utm_campaign.

You can now specify open tracking consent per recipient when sending transactional emails. The contactPixelTrackingConsent field controls whether recipient opens are tracked identifiably or anonymized.

How it works:

• contactPixelTrackingConsent: true — recipient has consented; the open pixel identifies them and the event is attributed to their email address
• contactPixelTrackingConsent: false — open event is anonymized and counted only in aggregate statistics

The Brevo CLI (@getbrevo/cli) has a new major version, 2.0.0, which introduces breaking changes. If you are on v1.1.1 or earlier, migrate to 2.0.0 — some commands may not work as expected on older versions.

Upgrade:

npm install -g @getbrevo/cli@latest
# or
yarn global add @getbrevo/cli@latest
# or
brew upgrade getbrevo/tap/brevo