Skip to content

feat(smtp): add contactPixelTrackingConsent to transactional email recipients - #38

Open
piyush-sib wants to merge 1 commit into
getbrevo:mainfrom
piyush-sib:feat/smtp-email-contact-pixel-tracking-consent
Open

feat(smtp): add contactPixelTrackingConsent to transactional email recipients#38
piyush-sib wants to merge 1 commit into
getbrevo:mainfrom
piyush-sib:feat/smtp-email-contact-pixel-tracking-consent

Conversation

@piyush-sib

@piyush-sib piyush-sib commented Aug 5, 2026

Copy link
Copy Markdown

Adds the per-recipient contactPixelTrackingConsent boolean to the to, cc and bcc item models of POST /v3/smtp/email, and to the same three recipient collections nested inside messageVersions:

  • SendTransacEmailRequestToItem / CcItem / BccItem
  • SendTransacEmailRequestMessageVersionsItemToItem / CcItem / BccItem

Typed typing.Optional[bool], exposed as the snake_case attribute contact_pixel_tracking_consent with the camelCase wire alias contactPixelTrackingConsent, declared with FieldMetadata + pydantic.Field(alias=..., description=...) exactly as the generator emits aliased optional properties.

Verified

  • ruff format --diff reports the hand-written code byte-identical to what the generator would emit; mypy clean
  • full test suite: 316 passed
  • Tri-state proven on the wire: True/False sent as true/false, key omitted entirely when unset
  • real sends to api.brevo.com/v3 on prod test account 3143293: 201, delivered

Why this is hand-written

This repo is Fern-generated and has not been regenerated since 2026-07-03, so the field never appeared in the published SDK even though the spec has carried it for weeks. Rather than keep waiting on a fern generate run, this is a hand-written stopgap that matches what the generator would emit. The next fern generate will overwrite these files — that is expected and fine, because the regenerated output contains the same field. No version bump: Fern owns versioning.

Six edits, not four: Fern inlines separate recipient copies for messageVersions, matching the 6 occurrences in the spec.

Description wording covers clicks too

Per-contact consent gates click links as well as the open pixel — an=1 is stamped at send time by DTSL/sendmail-personaliser#1231 and consumed by DTSL/redirection#2384, in production since 2026-08-03. The descriptions here reflect that. The matching spec wording update is DTSL/public-api#5895 (legacy client spec + OpenAPI bundle + generated v3, all in one PR). Until it merges this text is ahead of the published spec.

Related

🤖 Generated with Claude Code

…cipients

Add the per-recipient `contactPixelTrackingConsent` boolean to the `to`,
`cc` and `bcc` item models of `POST /v3/smtp/email`, and to the same three
recipient collections nested inside `messageVersions`:

- SendTransacEmailRequestToItem
- SendTransacEmailRequestCcItem
- SendTransacEmailRequestBccItem
- SendTransacEmailRequestMessageVersionsItemToItem
- SendTransacEmailRequestMessageVersionsItemCcItem
- SendTransacEmailRequestMessageVersionsItemBccItem

The field is `typing.Optional[bool]` exposed as the snake_case attribute
`contact_pixel_tracking_consent` with the camelCase wire alias
`contactPixelTrackingConsent`, declared with `FieldMetadata` +
`pydantic.Field(alias=..., description=...)` exactly as the generator
emits aliased optional properties. Descriptions are copied verbatim from
the OpenAPI spec. Tri-state semantics are preserved: `True`/`False` are
sent as `true`/`false`, and the key is omitted entirely when unset.

This is a hand-written stopgap: the repo is Fern-generated and the next
`fern generate` will overwrite these files. That is expected and fine —
the field is already in the OpenAPI spec, so the regenerated output will
contain it anyway. Package version is intentionally not bumped; Fern owns
versioning.

The description text covers both open (pixel) and click tracking: per-contact
consent gates click links as well, via an=1 stamped at send time by
sendmail-personaliser #1231 and consumed by redirection #2384 (in production
since 2026-08-03). The matching public-api spec wording update is still
pending, so these descriptions are currently ahead of the published spec text.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant