Integration advisories

Every now and then a change on our side requires you to update your code: an SDK with a mandatory fix, a payload that gained a field, an endpoint that changed shape. When that happens, we tell you — and only when that happens.

This channel is not a changelog. News, improvements and release notes live in the release-notes widget in the dashboard. Only things that break your integration if you do nothing come through here. The restriction is the point: a channel that fires only when you must act is a channel you read. If it fired on every release, you would learn to ignore it — and then you would not update.

You only get what affects you

An advisory is not blasted to the whole base. The audience is resolved at send time, crossing two things:

1. Which SDK and version your account runs. The official SDKs send a X-Bzapper-Client: bzapper-<language>/<version> header on every request.
2. Which features your account actually uses. A fix in document sending does not bother accounts that only send text.

A real example: when versions 0.4.0, 0.5.0 and 0.6.0 of the Python SDK shipped with media sending broken, the advisory went only to accounts running one of those versions and sending media. Accounts already on 0.6.1, or using only text and OTP, got nothing.

Plain HTTP integrations

If you call the API without an official SDK there is no version for us to identify — the header is not sent. You are still reachable through the features used axis, and you receive advisories about payloads and endpoints.

Where the advisory arrives

Channel	When
Dashboard	Always. Banner at the top; it goes away when you mark it as read.
Email	Always, to the account admins.
Browser notification	If you enabled it under Settings → Integration notices.
WhatsApp	Only with a verified phone and an explicit opt-in, in the same settings.
Webhook	The advisory.published event, if you subscribed to it.

WhatsApp requires verification and opt-in on principle: messaging a number nobody confirmed is exactly the unsolicited outreach we teach you to avoid. We do not do with our number what we ask you not to do with yours.

Reading them from the API

from bzapper import Client

bz = Client("bz_live_...")

for a in bz.list_advisories()["advisories"]:
    print(a["title"])
    print("What to do:", a["action"])
    bz.mark_advisory_read(a["id"])

Each advisory carries:

Field	What it is
id	Stable identifier of the advisory.
title	The headline.
impact	What breaks, concretely.
action	What you have to do. This is the field that matters.
link	Documentation with the details.
published_at	When the advisory went out.

In the other SDKs: listAdvisories() / markAdvisoryRead(id) (Node, PHP, Java) and ListAdvisories(ctx) / MarkAdvisoryRead(ctx, id) (Go).

Automating the response

Subscribe to the advisory.published event (see Webhooks) to react on your own — open a ticket, ping the team on Slack, trigger a dependency-bump bot:

{
  "event_type": "advisory.published",
  "payload": {
    "advisory_id": "sdk-python-media-typeerror",
    "title": "Python SDK: upgrade to 0.6.1 — media sending is broken",
    "impact": "Every media send call fails with TypeError…",
    "action": "Upgrade to 0.6.1 or newer: pip install --upgrade bzapper",
    "link": "https://docs.bzapper.com.br/sdks/python",
    "published_at": "2026-08-31T12:00:00Z"
  }
}

Keeping your account identifiable

Keep using the official SDK and do not strip the X-Bzapper-Client header. It is how we know you run an affected version — and, once you upgrade, how we stop bothering you.