Skip to content

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

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

feat(smtp): add contactPixelTrackingConsent to transactional email recipients#17
piyush-sib wants to merge 3 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 send_transac_email recipient models, per the updated swagger_definition_client.yml (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 contact_pixel_tracking_consent (BOOLEAN, optional, JSON key contactPixelTrackingConsent — accessor, attribute_map, swagger_types, initialize, ==, hash) to:

Model Used by
SendSmtpEmailTo send_smtp_email.to
SendSmtpEmailTo1 send_smtp_email.message_versions[].to
SendSmtpEmailCc cc + message_versions[].cc
SendSmtpEmailBcc bcc + message_versions[].bcc

Descriptions copied verbatim from the source swagger. Also updated the matching docs/*.md tables and bumped Brevo::VERSION 4.0.0 → 4.0.1.

Verification

  • ruby -c on all 4 models → Syntax OK
  • Round-trip check: SendSmtpEmailTo.new(email: ..., 'contactPixelTrackingConsent' => true).to_hash{:email=>..., :contactPixelTrackingConsent=>true}

Sibling PRs: getbrevo/brevo-java#27, getbrevo/brevo-csharp#19, brevo-go (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 contact_pixel_tracking_consent (BOOLEAN, JSON key
contactPixelTrackingConsent) to SendSmtpEmailTo, SendSmtpEmailTo1,
SendSmtpEmailCc and SendSmtpEmailBcc (accessor, attribute_map,
swagger_types, initialize, ==, hash) plus the matching docs tables, per
the updated swagger_definition_client.yml (DTSL/public-api#5895).
Bumps version 4.0.0 -> 4.0.1.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
swagger-codegen emits one 'test attribute' block per attribute, so the four
recipient specs were missing a block for contact_pixel_tracking_consent and a
future regeneration would have produced a spurious diff.

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