Buttondown's API changelog

2026-02-26

Thu, 26 Feb 2026 00:00:00 GMT

Each action inside an automation now carries its own timing, paving the way for multi-step sequences in a single automation. Previously, timing was a top-level field on the automation; starting with API version , it lives inside each action as a step . Here's what a multi-step automation looks like in the new format: { "trigger": "subscriber.confirmed", "actions": [ { "type": "send_email", "metadata": { "email_id": "welcome-email-id" }, "timing": { "time": "immediate" } }, { "type": "send_email", "metadata": { "email_id": "followup-email-id" }, "timing": { "time": "delay", "delay": { "unit": "days", "value": "3" } } } ] } If you're on an older API version, the top-level field still works exactly as before — the translation is handled behind the scenes.

2026-02-16

Mon, 16 Feb 2026 00:00:00 GMT

The and endpoints now reject bodies that start with YAML frontmatter (a delimiter followed by key-value pairs). This is almost always a sign of a bug in your integration rather than intentional email content, so the API now returns a with the code . If you need to bypass this restriction, pass the header: curl -X POST "https://api.buttondown.com/v1/emails" \ -H "Authorization: Token YOUR_API_KEY" \ -H "X-Buttondown-Live-Dangerously: true" \ -H "Content-Type: application/json" \ -d '{"subject": "My email", "body": "---\nstatus: sent\n---\nBody"}'

2026-02-09

Mon, 09 Feb 2026 00:00:00 GMT

The endpoint now accepts an optional parameter. When provided, the comment is attributed to that subscriber instead of the newsletter author. curl -X POST "https://api.buttondown.com/v1/comments" \ -H "Authorization: Token YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "email_id": "your-email-id", "subscriber_id": "your-subscriber-id", "text": "Great article, thanks for writing this!" }' The subscriber must belong to your newsletter and have access to comment on the email. If is omitted, the comment is attributed to the author as before.

2026-02-07

Sat, 07 Feb 2026 00:00:00 GMT

The endpoint now rejects SVG uploads by default, returning a error. SVG files aren't reliably rendered by most email clients, so this protects you from accidentally sending broken images to subscribers. If you need to upload SVGs anyway (for instance, if they're only used in your web archive), you can bypass this restriction with the header: curl -X POST "https://api.buttondown.com/v1/images" \ -H "Authorization: Token YOUR_API_KEY" \ -H "X-Buttondown-Live-Dangerously: true" \ -F "image=@logo.svg"

2026-02-06

Fri, 06 Feb 2026 00:00:00 GMT

Subscribers now include engagement counts and rates in the response: You can also filter and order by these rates: Order by / (ascending or descending, via ) Filter by / and / Rates are computed from engagement counts; if a subscriber has no deliveries, the rates are . Example: curl "https://api.buttondown.com/v1/subscribers" \ -H "Authorization: Token YOUR_API_KEY" \ -G \ --data-urlencode "ordering=-open_rate" \ --data-urlencode "open_rate__start=0.5" { "count": 1, "results": [ { "id": "9f4c9a1e-0d2c-4a44-8a4f-cc06e97a9df2", "email_address": "telemachus@buttondown.email", "delivered_count": 12, "open_count": 7, "clicked_count": 3, "open_rate": 0.5833, "click_rate": 0.25 } ] }

2026-01-24

Sat, 24 Jan 2026 00:00:00 GMT

You can now create and manage multiple API keys, each with granular permissions. This allows you to create separate keys for different integrations with only the access they need. Each API key can have independent permission levels for: Permission Controls Manage subscribers Manage emails and drafts Send emails Access newsletter settings Manage automations Manage forms Manage design settings Manage surveys Each permission can be set to (full access), (view only), or (no access). API keys can be managed in the Buttondown UI at API → Keys . Example of creating a read-only key for subscribers: curl -X POST "https://api.buttondown.com/v1/api-keys" \ -H "Authorization: Token YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "label": "Analytics dashboard", "subscriber_access": "read", "email_access": "read", "sending_access": "none", "administrivia_access": "none", "automations_access": "none", "forms_access": "none", "styling_access": "none", "surveys_access": "none" }' You can also regenerate, update, or delete API keys: Endpoint Action Update a key's label or permissions Delete a key Regenerate a key's secret (invalidates the old key)

2026-01-22

Thu, 22 Jan 2026 00:00:00 GMT

Added a new field to the Tag object. When set to , subscribers can add or remove this tag from their own profile via the subscriber portal . Example: curl -X POST "https://api.buttondown.com/v1/tags" \ -H "Authorization: Token YOUR_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "name": "Weekly digest", "color": "#4CAF50", "subscriber_editable": true }' When a tag is marked as subscriber editable: It appears as a checkbox in the subscriber portal Subscribers can toggle it on or off for themselves Tags not marked as subscriber editable can only be managed by the newsletter owner or via the API

2026-01-12

Mon, 12 Jan 2026 00:00:00 GMT

Added a new endpoint that sends a magic login link to a subscriber. This allows authors and integrations to trigger subscriber login flows programmatically, enabling subscribers to authenticate and access their subscription management portal. Example: curl -X POST "https://api.buttondown.com/v1/subscribers/{id}/send-magic-link" \ -H "Authorization: Token YOUR_API_KEY"

2026-01-01

Thu, 01 Jan 2026 00:00:00 GMT

Every ID in Buttondown's API is a UUID (e.g., ) with no indication of what it represents. UUIDs are great for databases, but they're not human-friendly. Starting with API version , we're introducing TypeIDs in Buttondown. A TypeID is a UUID with a readable type prefix. Prefixes like , , and make it immediately clear what kind of object an ID represents. such as for subscribers, for emails, and for tags. Here's what changes in the response: Old response (< 2026-01-01) New response (>= 2026-01-01) ─────────────────────────── ──────────────────────────── { { "id": "550e8400-e29b-41d4-...", "id": "sub_550e8400e29b41d4...", "email_id": "7c9e6679-7425-..." "email_id": "em_7c9e6679-7425..." } } No breaking changes to how you send requests. The API accepts both TypeIDs and UUIDs as input, but responses are version-aware. Send a request with and you'll always get TypeIDs back, regardless of what format you sent in. curl "https://api.buttondown.com/v1/subscribers" \ -H "Authorization: Token YOUR_API_KEY" \ -H "X-API-Version: 2026-01-01" This is now the default version for every new API key. If you are using an older API version ( ), nothing changes, your API responses still continue to contain UUIDs exactly as they are. But if you want to use our latest TypeID system, migrate through the dashboard or pass in your request headers.

2025-11-15

Sat, 15 Nov 2025 00:00:00 GMT

Added an optional header to the endpoint. When set to , this header enables test mode behavior for that specific draft send, similar to the global test mode setting. The draft will be rendered as if it's going to the specified subscribers, but then redirected to the newsletter author instead. This allows authors to preview how emails will appear to subscribers with different states (e.g., gifted subscribers, subscribers with specific metadata or tags). Example: curl -X POST "https://api.buttondown.com/v1/emails/{id}/send-draft" \ -H "Authorization: Token YOUR_API_KEY" \ -H "X-Buttondown-Test-Mode: true" \ -H "Content-Type: application/json" \ -d '{ "subscribers": ["subscriber-id-1", "subscriber-id-2"] }' When test mode is enabled via this header: Emails are redirected to the newsletter author's email address Subject lines are prefixed with Email body includes a test mode header showing the intended recipient All other email features (tracking, templating, etc.) work normally

2025-09-23

Tue, 23 Sep 2025 00:00:00 GMT

In what is the least impactful change in the history of Buttondown, we've increased the maximum length of the field from 1000 to 2000 characters. (We've also changed some related lengths, such as for RSS feeds and custom transactional emails, to match.)

2025-09-18

Thu, 18 Sep 2025 00:00:00 GMT

We've added support for tracking and filtering by churn dates in the Subscribers API: New field The schema now includes a field that tracks when a paid subscriber churned from their subscription. { "email": "subscriber@example.com", "churn_date": "2025-09-15T14:30:00Z", ... } New filters You can now filter subscribers by their churn date using two new query parameters: - Return only subscribers who churned on or after this date (format: ) - Return only subscribers who churned on or before this date (format: ) Example curl -X GET \ "https://api.buttondown.com/v1/subscribers?churn_date__start=2025-09-01&churn_date__end=2025-09-18" \ -H "Authorization: Token your-api-key" This is particularly useful for analyzing churn patterns and building retention reports for your paid newsletter.

2025-07-28

Mon, 28 Jul 2025 00:00:00 GMT

We've simplified the enum by removing the following deprecated types: - Now consolidated into with a specific - Now consolidated into with of - This type has been removed entirely This change streamlines subscriber management by using the existing field to provide more granular information about why a subscriber cannot receive emails, rather than having separate top-level types. If you were filtering subscribers by , you should now filter by instead. The specific reason for undeliverability can be determined by checking the field.

2025-07-13

Sun, 13 Jul 2025 00:00:00 GMT

We've added a new parameter to the endpoint that allows you to filter subscribers by their origin source. What's new You can now filter subscribers based on their source (e.g. , , , , ). Examples Get all subscribers added via API: Get subscribers from multiple sources (import and organic): Combine with other filters to create more specific queries: This filter works alongside all existing filters, making it easy to create powerful queries to understand your subscriber base better.

2025-06-26

Thu, 26 Jun 2025 00:00:00 GMT

We've added a field to the schema. This field is the name of the product which the subscriber is subscribed to. (You can override this by setting the metadata on the product in Stripe.)

2025-06-01

Sun, 01 Jun 2025 00:00:00 GMT

When we first launched Buttondown's API, we actually had three separate email endpoints: , , and , because we had three separate models for emails, drafts, and scheduled emails. graph TD /v1/emails --> Emails /v1/drafts --> Drafts /v1/scheduled_emails --> Emails This was an architectural mistake for many reasons, and we combined them into a single backing model, : graph TD /v1/emails --> |status=sent,in_flight| Emails /v1/drafts --> |status=draft| Emails /v1/scheduled_emails --> |status=scheduled| Emails We eventually realized the error of our ways and combined these, but to maintain backwards compatibility (before we had a versioning system!) we defaulted to have a behavior of only ever showing "real" emails that were in flight or sent. graph TD /v1/emails --> |status=sent,in_flight| Emails d["/v1/emails?status=draft"] --> |status=draft| Emails s["/v1/emails?status=scheduled"] --> |status=scheduled| Emails Fast forward three years, and this is still the case for non-obvious and increasingly tenuous reasons. We've cut a new version of the API that removes this little piece of duct tape, such that a call to will return all emails, regardless of status. (And you can still of course filter them by passing in as a query parameter.) graph TD /v1/emails --> before("Before 2024-04-15") /v1/emails --> after("After 2024-04-15") before --> |status=sent,in_flight| Emails after --> Emails d["/v1/emails?status=draft"] --> |status=draft| Emails s["/v1/emails?status=scheduled"] --> |status=scheduled| Emails

2025-05-30

Fri, 30 May 2025 00:00:00 GMT

TL;DR requests.post( "https://api.buttondown.com/v1/attachments", files={ "file": open("newsletter-guide.pdf", "rb") }, data={ "name": "Newsletter Guide" } ) We've added a new endpoint to the API that allows you to upload, list, and manage attachments for your emails. This brings the attachment functionality that was previously only available through the web interface to the API. The attachments API supports all the same file types as the web interface , and each attachment must be less than 2MB in size. The attachments feature is available on paid plans. Uploading an attachment Listing attachments Deleting an attachment

2025-05-19

Mon, 19 May 2025 00:00:00 GMT

TL;DR requests.get( "https://api.buttondown.com/v1/subscribers", params={ "date": ["2025-01-01", "2025-03-31"], // [!code --] "date__start": "2025-01-01", // [!code ++] "date__end": "2025-03-31", // [!code ++] }, ) Filters are a tricky thing to get correct. Dates are also a tricky thing to get correct. You combine the two of them, and you can be in a slightly painful world. When the API was very new, we added three date-based parameters: , , and , for filtering Subscribers by those fields. The idea was an implicit bracketing. You could supply two dates or one, and it was all a little implicit and messy. We've since standardized on a much more explicit and ergonomic approach, which is and , which is how the vast majority of the date parameters in the API work... except for those initial few, which changes today. We're cutting a new version of the API to finally migrate those old fields onto the new style. We're honoring existing call sites but encourage you to migrate to this new style for your own sanity and happiness. The old style of doing things: The new style of doing things:

2025-05-17

Sat, 17 May 2025 00:00:00 GMT

You can now request newsletter exports in JSON format by specifying the new field when creating an export. The old CSV functionality remains unchanged.

2025-05-14

Wed, 14 May 2025 00:00:00 GMT

We've expanded the Newsletter API to include the following new fields that allow for further programmatic customization of your newsletter: - Custom CSS styling for your newsletter emails - Custom CSS styling for your newsletter's web presence - URL to your newsletter's icon image - A brief description of your newsletter - URL to your newsletter's header or branding image These additions make it possible to programmatically customize the visual appearance of your newsletter both in email and on the web, giving you more control when integrating Buttondown as a headless email or newsletter provider. With these fields, you can now update your newsletter's branding and styling via the API, matching the capabilities previously only available through the web interface.

2025-04-17

Thu, 17 Apr 2025 00:00:00 GMT

We've expanded the enum to include the following new statuses: - The email is being sent out slowly to ensure deliverability. - The email is being resent to subscribers by Buttondown's systems in order to make sure all subscribers have received it. - The email is a transactional email used by a core workflow in your newsletter or Automations, and is not visible in your web archives nor sent out to subscribers. The first two statuses do not represent any changes to Buttondown's existing logic; we're not changing how we throttle or resend emails, just surfacing when we do so in a more legible way. The third status will (though does not yet!) represent a shift in how we approach things — specifically in how we approach sending automation-borne emails. No action will be required from you, but we're going to shift away from the current model of allowing "bespoke" emails defined within an automation towards a contract where all automations which send emails must reference an . (This doesn't represent a change in functionality — it's mostly internal plumbing — but is worth calling out.)

2025-04-14

Mon, 14 Apr 2025 00:00:00 GMT

We've expanded the subscriber filtering capabilities by adding support for UTM parameters. You can now filter subscribers by: - Find subscribers who arrived via specific marketing promotions - Filter by the channel that drove subscribers (social, email, etc.) - Filter by the specific source of subscribers We've also added a new filter to help you understand why subscribers are leaving. These parameters work just like existing filters - pass them as query parameters when listing subscribers :

2025-03-31

Mon, 31 Mar 2025 00:00:00 GMT

You can now provide an IP address when creating a subscriber . This will be used to determine the subscriber's location and validate their legitimacy (especially useful for folks submitting requests from a form that doesn't have CAPTCHA protection or similar anti-spam measures).

2025-03-25

Tue, 25 Mar 2025 00:00:00 GMT

You can now filter subscribers by their undeliverability status and specific reasons for being marked undeliverable. This helps you better manage your list health and diagnostics. A new field has been added to the model which can be used for filtering: You can also filter by undeliverability date range: Check out the undeliverability reasons documentation to see all possible values.

2025-03-01

Sat, 01 Mar 2025 00:00:00 GMT

RSS Feed Metadata Support RSS feeds just got smarter! Now you can attach metadata to your feeds and have it show up in your emails. Need to mark which site a feed is coming from or add some extra context? We've got you covered. What's new We added a field to the RSS feed endpoints. It's just a simple key-value dictionary where both keys and values are strings. You'll find the new field in: (when you fetch a feed) (when you create a feed) (when you update a feed) How to use it Here's a quick example: { "url": "https://example.com/feed", "behavior": "create_draft", "cadence": "every", "subject": "New post: {{ item.title }}", "body": "Check out my new post: {{ item.url }}", "label": "My blog feed", "metadata": { "source": "blog", "category": "tech" } } Once you've set this up, just use the metadata values in your templates like any other variable. Don't worry - this change won't break any of your existing integrations.

2025-02-26

Wed, 26 Feb 2025 00:00:00 GMT

We've added a new field to the Subscriber schema to help you track undeliverable subscribers! The schema now includes an field, which records when a subscriber was marked as undeliverable. This is similar to the existing field, but specifically for tracking when email delivery to a subscriber fails permanently. Additionally, you can now: Filter subscribers by and when listing subscribers Sort subscribers by or via the parameter This change makes it easier to track when subscribers become undeliverable and manage your subscriber list more effectively.

2025-02-12

Wed, 12 Feb 2025 00:00:00 GMT

We've added the ability to filter emails by subject! Now, when you list emails , you can pass in an optional parameter in the query to grab just the emails that match that. This parameter is substring-based (so "Hello" will match "Hello world", for example) and case-insensitive.

2025-02-06

Thu, 06 Feb 2025 00:00:00 GMT

We've removed the following fields from the object: This is a completely breaking change with no backwards compatibility or API version. If you're relying on these fields to be present (or are writing to these fields), then: You should migrate to using the field and setting the paywall therein. You should email us , because our analysis showed us that nobody was setting these fields programmatically! You can read more about the decision in the changelog entry for 2025-02-06 .

2025-01-02

Thu, 02 Jan 2025 00:00:00 GMT

In what may be the most niche breaking change ever, we've changed the field in the field of bulk actions to . Previously, when wanted to create a bulk action to add a tag to a list of subscribers, you could either specify a list of tag IDs: { "type": "apply_tags", "metadata": { "tag_ids": ["123", "456", "789"], "action": "add", } } Or you could specify a single tag: { "type": "apply_tags", "metadata": { "tag": "123", "action": "add", } } We've unified the two approaches to use instead of : { "type": "apply_tags", "metadata": { "tag": "123", // [!code --] "tag_id": "123", // [!code ++] "action": "add", } } The behavior of the endpoint has not changed, and we cut a new version of the API to make this backwards-compatible for existing callers.

2024-12-31

Tue, 31 Dec 2024 00:00:00 GMT

We've added the field to the model. This field is a date that indicates the date on which the subscriber upgraded to a paid subscription. Not only that, you can also filter subscribers by their upgrade date, or sort them by it.

2024-12-30

Mon, 30 Dec 2024 00:00:00 GMT

Breaking change : we've unshipped the field from emails, and replaced it with a more flexible field. The field is now a string that can be one of the following values: : comments are enabled : comments are disabled : comments are enabled, but only for paid enabled_for_paid_subscribers.

2024-12-14

Sat, 14 Dec 2024 00:00:00 GMT

In addition to deleting and creating images based on their , you can now list all of your images by using the new endpoint . ).

2024-12-11

Wed, 11 Dec 2024 00:00:00 GMT

When creating a new subscriber, Buttondown will now reject the request if a subscriber with the same email address already exists, even if that subscriber has unsubscribed or is otherwise in a "valid" state. We do this to protect the data and history of existing subscribers. However, if you're looking for behavior more akin to an upsert, you can provide a header of or in the request header: This is a slightly nuanced decision for you to make as an API caller; we've explained more about our default behavior and reasoning in the API endpoint docs .

2024-12-10

Tue, 10 Dec 2024 00:00:00 GMT

When creating an export of your Buttondown data , you can now specify two new fields to transform the shape and specificity of the data you receive: : a dictionary of parameters to filter the data you receive. : a list of columns to include in the export. Rather than just getting "every data point about every subscriber, ever": You can, say, grab just the email address and status of every subscriber in the past week : curl --request POST \ --url https://api.buttondown.com/v1/exports \ --header "Authorization: Token " \ --data '{"collections": ["subscribers"], "parameters": {"date": ["2024-12-03", null]}, "columns": ["email", "subscriber_type"]}' (We plan on augmenting this functionality to allow pulling specific metadata fields, too, but you can't do that quite yet.)

2024-12-09

Mon, 09 Dec 2024 00:00:00 GMT

When we added support for filtering subscribers by IP address , many of you wrote in asking for the same feature for referrer URLs. We've added support for this, too, and you can now filter subscribers by referrer URL:

2024-12-05

Thu, 05 Dec 2024 00:00:00 GMT

We've added support for filtering subscribers by IP address . This is, we imagine, a very niche feature, but we're glad to have it.

2024-09-30

Mon, 30 Sep 2024 00:00:00 GMT

Breaking change : we've made actually delete subscribers instead of just unsubscribing them. This change was implemented to align the API behavior with common REST conventions, where DELETE operations typically remove resources entirely. The difference between deleting and unsubscribing a subscriber is significant: Deleting a subscriber removes all their data from your list permanently. Unsubscribing a subscriber keeps their data but prevents them from receiving future emails. You can still unsubscribe users by calling and setting the field to . This method is preferable if you want to retain subscriber data while respecting their wish not to receive emails.

2024-08-15

Thu, 15 Aug 2024 00:00:00 GMT

Breaking change : we've combined the two fields of and on Emails into the field, which is now more flexible and composable. Historically, the and fields have been intersections rather than unions : An email with and would only be sent to subscribers with the tag. An email with and would be sent to subscribers with the and tag. An email with and would be sent to subscribers with the and tag except for subscribers with the tag. This meant it was impossible to model more complex filters or audiences, such as: Sending an email to subscribers tagged foo or bar. Sending an email to subscribers tagged foo and either bar or baz. Sending an email to subscribers tagged foo or those with a given metadata key-value pair. Our new field allows you to express these kinds of filters in a more flexible way by letting you nest specific fields. It's more verbose, but within that verbosity lies power. Here are some examples of how you can use the field to express the same filters as above. A simple filter Before { "email": { // ...other fields... "included_tags": ["foo"], "excluded_tags": [] } } After { "email": { // ...other fields... "filters": { "predicate": "and", "groups": [], "filters": [ { "operator": "contains", "field": "subscriber.tags", "value": "foo" } ] } } } A more complex filter Before { "email": { // ...other fields... "included_tags": ["foo", "bar"], "excluded_tags": ["baz"] } } After { "email": { // ...other fields... "filters": { "predicate": "and", "groups": [], "filters": [ { "operator": "contains", "field": "subscriber.tags", "value": "foo" }, { "operator": "contains", "field": "subscriber.tags", "value": "bar" }, { "operator": "not_contains", "field": "subscriber.tags", "value": "baz" } ] } } } (Note that these changes do not apply to the RSS feeds endpoints, which similarly have taken an optional field. That change will come too, in good time.) Super-breaking change : we're also removing the and filters from the list endpoint. This is not backwards compatible: I investigated the possibility of adding a new field to the list endpoint, but decided that it would be too confusing and too onerous for what it achieves. No active API clients have used either filter in the past 90 days, so we're deeming it safe; if you have a specific use case in mind that hinged on this functionality, email us and we can discuss your options.

2024-08-01

Thu, 01 Aug 2024 00:00:00 GMT

Breaking change : we've renamed two fields on Subscribers : is now is now The shape and mechanics of these fields have not changed, but the names are now more consistent with other API fields.

2024-07-13

Sat, 13 Jul 2024 00:00:00 GMT

Breaking change : we've removed the field from Email . If you're interested in setting a canonical URL for your newsletter (because, for example, you're cross-posting it from a different CMS or platform), you'll want to use the field instead.

2024-06-27

Thu, 27 Jun 2024 00:00:00 GMT

Breaking change : we've removed the ability to send non-final emails like drafts from /v1/subscribers/{id}/emails . Such requests will now return an error message: { "code": "email_invalid_status", "detail": "You can't programmatically send emails with status 'draft'. Finalize the email first or use the /v1/emails/{id}/send-drafts endpoint instead.", "metadata": { "email_status": "draft", "email_id": "{{ email.id }}", "subscriber_id": "{{ subscriber.id }}" } } This is a breaking change, and apologies if you suddenly started getting 400s as a result of it, but the fix should hopefully be simple: just migrate that call to /v1/emails/{id}/send-draft instead.

2024-06-21

Fri, 21 Jun 2024 00:00:00 GMT

We've added two new top-level routes for you to query from: These endpoints were previously sequestered under the and routes, respectively. Now, you can query them directly without needing to implicitly filter on a given survey or email, making it easier to batch large bits of data across multiple sources.

2024-05-22

Wed, 22 May 2024 00:00:00 GMT

We've added as a filter to the endpoint , which allows you to filter subscribers by the import in which you brought them in. (It's not easy to actually get that ID from the API at the moment, we know. More stuff coming soon in that area!)

2024-04-03

Wed, 03 Apr 2024 00:00:00 GMT

We've launched the endpoint, which allows you to create, list, and delete comments on emails.

2023-08-23

Wed, 23 Aug 2023 00:00:00 GMT

You can now filter emails by and in the endpoint.

2023-08-21

Mon, 21 Aug 2023 00:00:00 GMT

Added , which allows you to create and list webhooks that will be called when certain events happen in your account.

2023-07-23

Sun, 23 Jul 2023 00:00:00 GMT

Added , , and to the endpoint. If these fields are not present, the values will be inferred from a provided .

2022-11-24

Thu, 24 Nov 2022 00:00:00 GMT

Added , which returns aggregated information about opens, clicks, and other events for a given email that you've sent.

2022-11-19

Sat, 19 Nov 2022 00:00:00 GMT

Removed the , , and endpoints. The behavior of all three endpoints have been subsumed into and : you can create (or list) drafts by specifying you can create (or list) scheduled emails by specifying you can list unsubscribers by specifying (Note: this field was renamed from to in 2024-08-01 )

2022-03-08

Tue, 08 Mar 2022 00:00:00 GMT

Added support for filtering emails in on and .

2021-11-26

Fri, 26 Nov 2021 00:00:00 GMT

Took the ability to send specific emails to subscribers out of beta; added , which allows you to send reminders to your subscribers to confirm their email address.

2021-08-27

Fri, 27 Aug 2021 00:00:00 GMT

Added support for Exports via the endpoint.

2021-01-02

Sat, 02 Jan 2021 00:00:00 GMT

Added support to set and retrieve metadata on Emails.

2020-12-23

Wed, 23 Dec 2020 00:00:00 GMT

Added deletion and update abilities to the Scheduled emails endpoint, giving you much more programmability than the hitherto append-only state of the world.

2020-12-09

Wed, 09 Dec 2020 00:00:00 GMT

Added a deletion endpoint to the Images endpoint, allowing you to delete unused images.