> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developers.brevo.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developers.brevo.com/_mcp/server.

# Changelog

## October 8, 2026

# Brevo Developer Terms and site footer

* Added the [Brevo Developer Terms](https://developers.brevo.com/docs/apps-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.

## October 7, 2026

# Integration guides for app builders and automation tools

## Added

* **Integrations** — Six new guides under Messaging API > Integrations show how to send email through Brevo from popular app builders and automation tools: [Base44](/docs/base44-integration), [Bolt.new](/docs/bolt-new-integration), [Lovable](/docs/lovable-integration), [n8n](/docs/n8n-integration), [v0](/docs/v0-integration), and [Supabase Auth emails over SMTP](/docs/supabase-smtp-integration). The Supabase guide is also linked from [SMTP relay integration](/docs/smtp-integration).

## Improved

* **Quickstart and Getting started** — Both now point to [machine-to-machine (M2M) authentication](/docs/oauth-m2m-authentication) for server-to-server integrations, and the Authentication card on the [Overview](/docs/getting-started) mentions it. See [Quickstart](/docs/quickstart).
* **"On this page" navigation** — The table of contents on guide pages now highlights the sections currently in view along a vertical track.

## October 6, 2026

# OAuth 2.0 machine-to-machine (M2M) authentication

## Added

* **[Machine-to-machine (M2M) authentication](/docs/oauth-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](/docs/authentication-schemes).
* **[CLI reference](/docs/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.

## Improved

* **[OAuth 2.0](/docs/oauth)** — The page now explains the two OAuth flows, machine-to-machine and OAuth apps (user consent), when to use each, and how they compare with API keys.
* **[Authentication schemes](/docs/authentication-schemes) and [API key authentication](/docs/api-key-authentication)** — The OAuth 2.0 option now covers both flows, and API key authentication points new server-to-server integrations to M2M.

Request an explicit `scope` when you get a token. A token requested without one is currently issued with all of the app's scopes.

## September 3, 2026

# Loyalty transaction status renamed, new balance field

## Breaking changes

* **[Begin transaction](/reference/begin-transaction) / [Cancel transaction](/reference/cancel-transaction) / [Complete transaction](/reference/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

* **[Begin transaction](/reference/begin-transaction) / [Cancel transaction](/reference/cancel-transaction) / [Complete transaction](/reference/complete-transaction)** — New `balance` field on the transaction response: the contact's total balance for that balance definition after the transaction was applied. Only present when the transaction actually updated the balance (completed or auto-completed).

## September 2, 2026

# Loyalty subscription details and image gallery naming guidance

## 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](/reference/get-parameter-subscription-info).

## Improved

* **Upload image to gallery (`POST /emailCampaigns/images`)** — Clarified the `name` field description to note it should include the file extension (e.g. `product-banner.png`). See [Upload image to gallery](/reference/upload-image-to-gallery).

## August 14, 2026

## Get the records associated with an object record

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.

**Example**

```curl
curl --request GET \
     --url 'https://api.brevo.com/v3/objects/contact/associated-records?email=jane.doe@example.com' \
     --header 'accept: application/json' \
     --header 'api-key: YOUR_API_KEY'
```

**Reference:**

[Get the records associated with an object record](/reference/custom-objects/get-associated-records)

**Guide updated:**

[Custom objects management](/docs/custom-objects-management)

## August 13, 2026

## `brevo app upload` replaces `brevo app update`

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.

Read the docs

## Recover a project with `brevo app scaffold`

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.

Read the docs

## `brevo app create` asks separately before scaffolding

`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.

Read the docs

## August 6, 2026

# Product import guide now documents alternativePrice

The **[Import your products](/docs/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](/reference/create-update-product) and [Create products in a batch](/reference/create-update-batch-products).

## July 30, 2026

## JS Tracker — document `EXT_ID` in `Brevo.identify()`

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)](/docs/identify-users-js)

## July 21, 2026

## Transactional Email — clarified `contactPixelTrackingConsent` behavior

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.

This corrects earlier wording that suggested a missing field would block the send and generate an error event. Behavior is unchanged — this is a documentation clarification only.

**Endpoint updated:**

[Send a transactional email](/reference/send-transac-email) — `POST /smtp/email`

## July 20, 2026

## Email Campaigns — UTM parameter customization

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`.

**Response fields** (when retrieving campaigns):

* `utmCampaignValue` — The `utm_campaign` value associated with the campaign. Only present if set.
* `utmContent` — The `utm_content` value. Only present if set.
* `utmTerm` — The `utm_term` value. Only present if set.
* `utmID` — The campaign ID used as `utm_id` parameter. Only present if UTM campaign tracking with ID is enabled.
* `utmMedium` — The `utm_medium` value. Set to "EMAIL" when UTM campaign tracking is enabled.
* `utmSource` — The `utm_source` value. Set to "Brevo" when UTM campaign tracking is enabled.

**Endpoints updated**:

* [Create an email campaign](/reference/create-email-campaign) — `POST /emailCampaigns`
* [Update an email campaign](/reference/update-email-campaign) — `PUT /emailCampaigns/{campaignId}`
* [Get email campaigns](/reference/get-email-campaigns) — `GET /emailCampaigns`
* [Get an email campaign](/reference/get-email-campaign) — `GET /emailCampaigns/{campaignId}`

All new fields are optional and backwards compatible — existing integrations continue to work without changes.

## Transactional Email — per-contact pixel tracking consent

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

**When the feature is enabled for your account**, set `true` or `false` per recipient to control open tracking. 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. When the feature is not enabled for your account, the field is ignored.

**Available on all recipient types:**

The field can be set on any recipient in the `to`, `cc`, `bcc`, and `messageVersions` arrays.

**Endpoint updated:**

[Send a transactional email](/reference/send-transac-email) — `POST /smtp/email`

## July 2, 2026

# Brevo CLI v2.0.0 — upgrade notice

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:

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

Confirm your version with `brevo --version`. See the latest release on [npm](https://www.npmjs.com/package/@getbrevo/cli), and the full [CLI reference](/docs/cli-reference) for current commands.

# Deals API — filter by owner, stage, and pipeline

`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)

Retrieve stage and pipeline IDs from `GET /crm/pipeline/details/{pipelineID}`.

## June 30, 2026

# Consent Groups API and Wallet pass install URLs

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

## Consent Groups

Consent groups represent categories of contact opt-in/opt-out preferences. The following endpoints are available when the Consent Groups feature is enabled for your account (they return `403` with code `CONSENT_GROUP_NOT_ENABLED` otherwise):

* [List all consent groups](/reference/get-consent-groups) — `GET /contacts/consent-groups`. Paginated; filterable by `id`, `name`, and `signupMode`.
* [Create a consent group](/reference/create-consent-group) — `POST /contacts/consent-groups`.
* [Get a consent group](/reference/get-consent-group) — `GET /contacts/consent-groups/{id}`.
* [Update a consent group](/reference/update-consent-group) — `PUT /contacts/consent-groups/{id}`. Updates name, description, or signup mode.
* [Delete a consent group](/reference/delete-consent-group) — `DELETE /contacts/consent-groups/{id}`. Removes it from all associated contacts.

Two existing operations were extended:

* [Import contacts](/reference/import-contacts) (`POST /contacts/import`) accepts a new optional `consentGroupIds` field to add all imported contacts to the specified consent groups.
* [Get a contact's details](/reference/get-contact-info) (`GET /contacts/{identifier}`) now returns a `consentGroups` array showing each consent group the contact belongs to and their subscription status. This is present only when the Consent Groups feature is enabled.

## Wallet

* [Get a pass installation URL for a contact](/reference/get-wallet-pass-install-url) — `GET /wallet/passes/{passId}/installUrl/{contactId}`. Generates a per-contact wallet installation URL. The returned URL points to the pass installation page and encodes the pass, contact, and organization identifiers as an encrypted token, so it can be shared (email, SMS, QR code) for the contact to add the pass to their Apple Wallet or Google Wallet.

## June 3, 2026

# OAuth apps now support scopes

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.

## What's new

* Request granular permissions per app (e.g. `contacts:read`, `contacts:write`, `crm:read`, `crm:write`).
* New apps default to `contacts:read`, `contacts:write`, `crm:read`, `crm:write`.
* Manage scopes from the CLI:
  * `brevo app available-scopes` lists every scope the Brevo identity provider supports.
  * Edit `auth.scopes` in `app-config.json` and run `brevo app upload` to add scopes to an existing app.

## Learn more

* [Scopes](/docs/oauth-scopes) — full catalog and how to request them
* [CLI reference](/docs/cli-reference) — `available-scopes` and `app upload` commands

## May 14, 2026

# Major SDK releases: Node.js v6.0.0, PHP v5.0.0, Python v5.0.0

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.

## Why this release

Most of the breaking changes come from an internal effort at Brevo to make our API endpoints, parameters and models more **self-descriptive**. The goal is to make the public surface easier to read at a glance — both for developers and for AI agents working against the Brevo API — so that names, shapes and required fields convey intent without needing to cross-reference external docs.

Concretely:

* Consistent parameter naming across languages
* Payload wrappers that reflect what each endpoint actually does (e.g. `{ events: [...] }`)
* Filter keys that match the wire format
* Model fields renamed or removed where the previous names were ambiguous
* Tightened types (`DateTime`/`datetime` instead of `string` for dates, typed unions instead of generic maps)

We've kept the previous major lines supported so you can adopt the new versions on your own timeline.

## Releases

### Node.js — [`@getbrevo/brevo` v6.0.0](https://github.com/getbrevo/brevo-node/releases/tag/v6.0.0)

* Full changelog: [Node.js SDK changelog](/docs/sdks-libraries/node-changelog)
* New `auth` constructor option for custom `AuthProvider` injection (existing `apiKey` continues to work unchanged)
* Breaking: `getCompanies` filter key, `createBatchEvents` payload shape, Balance endpoints, CRM types, model field removals/renames

### PHP — [`getbrevo/brevo-php` v5.0.0](https://github.com/getbrevo/brevo-php/releases/tag/v5.0.0)

* Full changelog: [PHP SDK changelog](/docs/sdks-libraries/php-changelog)
* Breaking: `GetCompaniesRequest::filters` renamed, `Event::createBatchEvents` wrapper, Balance/CRM/Email Campaigns model changes, date fields tightened to `DateTime`, associations union flattened

### Python — [`brevo-python` v5.0.0](https://github.com/getbrevo/brevo-python/releases/tag/v5.0.0)

* Full changelog: [Python SDK changelog](/docs/sdks-libraries/python-changelog)
* Breaking: `get_companies` keyword renamed, `create_batch_events` keyword change, Webhooks signature change, shape collapses (`Union[str, List[str]]`, `Dict[str, int]`), 21 top-level imports removed
* Every change applies symmetrically to both `Brevo` (sync) and `AsyncBrevo`

## Holding on the previous major

If you're not ready to migrate, pin to the previous major line — both lines will continue to receive wire-compatibility fixes.

```bash
# Node.js
npm install @getbrevo/brevo@^5.0

# PHP
composer require getbrevo/brevo-php:^4.0

# Python
pip install "brevo-python>=4,<5"
```

Each SDK README includes an "Upgrading from v4.x / v5.x" guide with the full list of breaking changes and code examples.

## May 12, 2026

# Deprecation Notice: POST /contacts/batch

**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](/reference/import-contacts) API.

## What you need to do

* Migrate all bulk-update operations to `/v3/contacts/import`.
* The deprecated endpoint may stop functioning after the deprecation date.

## Why this change?

* Improved performance and scalability
* More consistent validation and error handling
* Supports larger and asynchronous contact imports

## May 1, 2026

# Contacts category attributes: valueStr field, and Ecommerce product search and alternative price

## Breaking changes

* **[Get contact attributes](/reference/get-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.

## Added

* **[Get contact attributes](/reference/get-attributes)** — New `valueStr` (string) field added to category-type attribute enumeration items. Always contains the original string representation of the value (e.g. `"en"`, `"fr"`, `"1"`). Use `valueStr` when the attribute value is non-numeric or when you need the exact string form alongside the numeric `value` field. `valueStr` is now a required field in the enumeration item schema.
* **[Get products](/reference/get-products)** — New `search` query parameter for simultaneous search across SKU, name, and ID fields. Results are returned in priority order: exact SKU match > SKU prefix match > name match > ID match.
* **[Get products](/reference/get-products)** — New `alternativePrice` filter parameters: `alternativePrice[lte]`, `alternativePrice[gte]`, `alternativePrice[lt]`, `alternativePrice[gt]`, `alternativePrice[eq]`, `alternativePrice[ne]`.
* **[Get products](/reference/get-products) / [Create or update a product](/reference/create-update-product)** — New `alternativePrice` (float) field on product objects, available in GET responses and supported in POST requests.

## April 27, 2026

# Coupons webhooks documentation

* **Marketing Webhooks** — Added a new [Coupons webhooks](/docs/marketing-webhooks#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.

## April 21, 2026

# Batch events body wrapper, contact merge ID response, and loyalty transaction filter

## 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.

## Added

* **Create contact (`POST /contacts`)** — New `getId` field (boolean, default `false`). When set to `true` alongside `forceMerge: true`, the response includes the `id` of the surviving contact after the merge. Useful when you need to reference the retained contact record immediately after creation.
* **Loyalty transaction history (`GET /loyalty/balance/programs/{pid}/transaction-history`)** — New `loyaltySubscriptionId` query parameter for filtering transaction history by a specific loyalty subscription.

## April 17, 2026

# API specification overhaul: accuracy, completeness, and breaking corrections

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.

## Breaking changes

These are corrections to the spec that reflect reality but will require updates to code relying on the previously incorrect types.

* **Process endpoints (`GET /processes`, `GET /processes/{processId}`)** — Import `info` fields (`invalid_emails`, `duplicate_contact_id`, `duplicate_ext_id`, `duplicate_email_id`, `duplicate_phone_id`, `duplicate_whatsapp_id`, `duplicate_landline_number_id`) are now typed as `string` (URL to a CSV report) instead of `integer`. This corrects the type for all fields, not just `duplicate_email_id` which was previously patched.
* **Process endpoints** — The following fields have been removed from the response schema as they are not returned by the API: `error`, `created_at`, `completed_at`, and `info.export` (with `total_records` and `file_size`).
* **Process endpoints** — `GET /processes/{processId}` 404 error code corrected from `invalid_parameter` to `document_not_found`.
* **Account endpoint (`GET /account`)** — `dateTimePreferences` object removed from the response schema (including `timezone`, `timeFormat`, `dateFormat`). `startDate`, `endDate`, and `users` removed from the required fields list in plan objects.
* **Webhooks** — Event names corrected: `listAdditions` → `listAddition`, `hardBounces` → `hardBounce`.
* **Feeds (`GET /feeds`, `GET /feeds/{uuid}`)** — `alias`, `isInternal`, `personalization`, `defaultAttr`, and `defaultContact` fields removed from the response schema as they are not returned by the API.
* **Export webhook history (`POST /webhooks/export`)** — `messageId` field corrected from `integer` to `string`.
* **Domain creation (`POST /senders/domains`)** — Domain name validation changed from a custom regex pattern to `format: hostname`.
* **Pagination minimums** — `limit` minimum on `GET /processes` and `maxRetries` minimum on feed endpoints raised from `0` to `1`.

## Added

* **`GET /account`** — `400` error response now documented.
* **Master account endpoints** — `400` error responses now documented on `GET /corporate/groups/{id}`, `GET /corporate/groups`, `GET /corporate/admin-users`, `GET /corporate/ips`.
* **Webhook associations (`PUT /crm/objects/{object_type}/records`)** — Associations now support an `action` field (`link` or `unlink`), enabling removal of associations in the same upsert request. Added three illustrative request body examples.
* **Marketing webhook events** — `contactUpdated` and `contactDeleted` added as supported event types for marketing webhooks.

## Improved

* **Process endpoints** — `info` and `export_url` fields now clearly scoped: `info` is only returned for completed `IMPORTUSER` processes; `export_url` is only returned for `SEARCH_EXPORT_USERS`, `SEARCH_EXPORT_USERS_API`, `CAMPAIGN_USER_DETAILS`, and `EXPORT_WEBHOOK` process types.
* **Feeds** — Auth fields (`username`, `password`, `token`) now documented as conditionally returned based on `authType`. `cache` default corrected to `true`.
* **Custom objects upsert** — Significantly expanded description with upsert semantics, `id` vs `ext_id` behavior, attribute key vs label guidance, and async processing details.
* **Organization / User endpoints** — Added descriptions to `GET /organization/invited/users`, `PUT /organization/user/invitation/revoke/{email}`, `PUT /organization/user/invitation/{action}/{email}`, `GET /organization/user/{email}/permissions`.
* **Sub-account deletion** — `DELETE /corporate/subAccount/{id}` now includes a description warning that deletion is permanent and unrecoverable.
* **Missing summaries** — Added `summary` fields to several Senders, Domains, Webhooks, and Organization endpoints that previously had none.

_Showing the 20 most recent of 127 entries. Append `/llms.txt` to the changelog URL for the complete index._