Skip to content

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

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

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

Conversation

@piyush-sib

@piyush-sib piyush-sib commented Jul 27, 2026

Copy link
Copy Markdown

Summary

Adds the per-recipient contactPixelTrackingConsent boolean to the SendTransacEmail recipient models, per the updated source swagger (DTSL/public-api#5895). This is the SDK counterpart of the per-contact pixel tracking consent feature on POST /v3/smtp/email (backend live since 2026-07-15; documented on developers.brevo.com).

Changes

Added ContactPixelTrackingConsent *bool (json:"contactPixelTrackingConsent,omitempty") to:

Model Used by
SendSmtpEmailTo SendSmtpEmail.To
SendSmtpEmailTo1 SendSmtpEmail.MessageVersions[].To
SendSmtpEmailCc Cc + MessageVersions[].Cc
SendSmtpEmailBcc Bcc + MessageVersions[].Bcc

Also updated the matching docs/*.md tables and the api/swagger.yaml snapshot (4 recipient definitions).

Note on *bool: the field is a pointer (unlike other bools in this SDK) because the API is tri-state — true (identified tracking), false (anonymise), absent (unknown-consent). A plain bool with omitempty could never transmit false.

Verification

  • go build ./... + go vet ./lib → clean
  • Round-trip: {Email, ContactPixelTrackingConsent: &false}{"email":"a@b.c","contactPixelTrackingConsent":false}; unset → field omitted

Sibling PRs: getbrevo/brevo-java#27, getbrevo/brevo-csharp#19, getbrevo/brevo-ruby#17 (same field).

🤖 Generated with Claude Code

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. A follow-up commit here extends the field description accordingly ("open (pixel) and click tracking", false anonymises both events). Comment/doc text only — no type, signature or serialisation change.

Matching spec wording: DTSL/public-api#5895 (single spec PR — legacy client spec + OpenAPI bundle + generated v3).

…cipients

Adds the per-recipient ContactPixelTrackingConsent *bool (JSON key
contactPixelTrackingConsent) to SendSmtpEmailTo, SendSmtpEmailTo1,
SendSmtpEmailCc and SendSmtpEmailBcc, plus the matching docs tables and
the api/swagger.yaml snapshot, per the updated source swagger
(DTSL/public-api#5895). Pointer type so an explicit false (anonymise)
is still serialized while unset is omitted.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…iption

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 description added
earlier in this PR said "open (pixel) tracking" only, which understated what
passing false actually does.

Four phrase-level edits, applied to every occurrence (to/to_1/cc/bcc plus the
docs/ tables):

  - "for open (pixel) tracking" -> "for open (pixel) and click tracking"
  - "consented to open tracking, in which case the open pixel identifies the
    recipient" -> "consented to open and click tracking, in which case the
    open pixel and tracked links identify the recipient"
  - "anonymise the open event" -> "anonymise the open and click events"
  - "the open is anonymised unless" -> "the open and click are anonymised
    unless"

Comment/doc text only: no type, signature or serialisation change. Matching
spec wording update is DTSL/public-api#5900 (bundle) and #5895 (legacy client
spec).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@piyush-sib
piyush-sib force-pushed the feat/smtp-email-contact-pixel-tracking-consent branch from 8d32a1a to 6aad08c Compare August 5, 2026 07:03
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