Changelog

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.

New endpoint: DELETE /loyalty/config/programs/{pid}/contact/{cid}

Removes a contact from a loyalty program subscription. See the Loyalty API reference for details.

Rate limits: Loyalty endpoints now have documented rate limits across all account tiers.

We’ve released a beta version of the Python SDK (v4.0) with significant improvements including native async support via AsyncBrevo, Pydantic-based typed models, automatic retries with exponential backoff, and a custom httpx client support.

You can learn more on the dedicated guide here: https://developers.brevo.com/docs/api-clients/python

Updated the Conversations webhooks documentation with new fields and corrections.

Message object — new fields:

• rawUnsafeHtml — Raw unsanitized HTML of the message
• subject — Email subject line (present for email-source conversations)
• isSentViaJsApi — true for messages sent via the JS API
• sourceMessageId — Original message ID from the source platform
• from, to, replyTo, cc, bcc — Email conversation fields
• isForward — true if the message is a forwarded message