The events API now reads from one event store

GET /v1/events moves onto the same event store that powers webhooks

June 23, 2026
Breaking API change

This is a backwards-incompatible change to Buttondown's API. Pinning your newsletter or request to an older API version keeps the previous behavior where a version was cut for it.

We've moved the events API onto Buttondown's unified event store — the same source of truth that powers webhooks and our other event sources. An event you read from GET /v1/events is now the same record you can cross-reference everywhere else events appear, instead of a parallel copy maintained in a separate, older store that we're retiring.

This is a backwards-incompatible change to GET /v1/events and GET /v1/events/{id}, and we've deliberately chosen not to preserve the old behavior: keeping a second event store alive purely for compatibility would defeat the point of having a single source of truth. It does not introduce a new API version.

  • Event IDs now use the ext_evt_ prefix (previously em_evt_). IDs returned before this date are no longer retrievable via GET /v1/events/{id} — refetch from the list endpoint to obtain current IDs. If you deduplicate events by ID, expect to see each event once more around the cutover.

  • The event_type filter now accepts a narrower set of values: bounced, clicked, complained, delivered, opened, rejected, replied, and unsubscribed. Internal-only types the filter previously accepted (sent, attempted, deferred, and the activation_* / subscription_confirmed_* transactional types) now return a 422 and no longer appear in the unfiltered feed.

  • Event metadata is normalized to a consistent set of keys — code, url, ip_address, os, and browser, plus from, subject, html, and text on replied events. Other incidental keys are no longer returned.

If this breaks an integration you rely on, please reach out — we'd like to help you migrate.

Buttondown is the last email platform you’ll switch to.