Changelog

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

GET /crm/deals now documents three additional query filters, so you can narrow results server-side instead of fetching every deal and filtering client-side:

• filters[attributes.deal_owner] — filter by deal owner (pass the owner’s account email)
• filters[attributes.deal_stage] — filter by stage (pass the stage ID)
• filters[attributes.pipeline] — filter by pipeline (pass the pipeline ID)

New endpoints and fields have been added to the API for managing consent groups and generating wallet pass installation URLs.

OAuth apps can now declare scopes — the specific permissions your app requests from a Brevo user. Scopes are shown to the user on the consent screen and embedded in the issued access token, so your integration only gets the access it actually needs.

We’ve released the next major version of our three official SDKs. These are opt-in major releases with breaking changes — your existing v4.x/v5.x integrations are not affected unless you upgrade.

Effective: 30 October 2026

The Update Multiple Contacts endpoint (POST /contacts/batch) will be deprecated on 30 October 2026. This endpoint is being replaced by the newer and more scalable POST /v3/contacts/import API.

Breaking changes

• Get contact attributes — The value (integer) field in category-type attribute enumerations now returns 0 for non-numeric values (e.g. language codes "en", "fr"). Previously these values may have been returned as distinct integers. Clients using value as a unique identifier for category enum items must migrate to the new valueStr field to correctly distinguish these entries.

• Marketing Webhooks — Added a new Coupons webhooks section documenting the unique_coupon_sent event. This event is triggered when a unique coupon code is sent to a contact from a coupon collection, enabling integrators to track coupon delivery, reconcile inventory, and sync coupon status into external systems.

Breaking changes

• Batch track events (POST /events/batch) — The request body schema has changed. The array of events must now be wrapped in an object under an events key. Previously accepted: [{...}, {...}]. Now required: {"events": [{...}, {...}]}. Additionally, event_name and identifiers are now explicitly marked as required fields on each event object.

This release reflects a major rework of the OpenAPI specification to bring it in line with actual API behavior. Some changes correct inaccuracies between the spec and the responses, some generated SDK types will change. See the breaking changes section before upgrading.

Fixed

• Process endpoints — duplicate_email_id is now typed as a string (URL to a CSV file) instead of an integer. The legacy in_process status value is now handled correctly across all SDKs.
• Event endpoints — contact_properties and event_properties now accept boolean values in createEvent and createBatchEvents.
• Contact endpoints — attributes now accepts plain integers in createContact and updateContact. PHP users no longer need to cast integers to float.

New endpoints, new fields, and API improvements across all three SDKs.

Ecommerce — New product fields

Two new fields are now supported on the POST /products and POST /products/batch endpoints, as well as the GET /products/{id} response:

• brand — Brand name of the product. String, max 128 characters. Example: "Adidas".
• description — Description of the product. String, max 3000 characters. Example: "Shoes for sports".

Bug fixes, type corrections, and a deprecation across all three SDKs.

Added a new Loyalty section to the Guides tab with six pages covering the full Loyalty API integration workflow.

• Overview — key concepts, data model, and transaction lifecycle
• Set up a program — create balance definitions, configure tiers, and publish
• Enroll members — subscribe contacts and link to eCommerce orders
• Credit & debit points — full transaction lifecycle including balance orders
• Read member data — fetch balances, tier status, and vouchers
• Best practices — integration patterns, performance tips, and use cases

Added POST /events/batch to the Events API. This endpoint allows sending multiple events in a single request, each with its own contact identifiers, event properties, and optional object associations.

The response supports partial success — if some events fail validation, the API returns a 207 status with a breakdown of successful and failed events, including per-event error messages.

The Brevo MCP server has been updated with improved security, simplified maintenance, and rate limiting.

What changed:

• Authentication method: MCP tokens are no longer passed in the URL. They are now transmitted securely via the HTTP Authorization: Bearer <token> header. All previous URL patterns containing /{token} are no longer valid.
• Auto-generated tools: The 193 MCP tools are now automatically generated from the Brevo OpenAPI specification, eliminating discrepancies between the API and MCP server.
• Rate limiting: Request limits have been added to protect services from abuse.
• New tool support: Integration guides now cover Windsurf, VS Code (GitHub Copilot), and Claude Code CLI in addition to Claude Desktop, Cursor, and Cline.