We’ve added a delivered webhook event that will trigger when we receive a successful SMTP response from the receiving server. 

You receive a send event when the message reaches our system, a deferral event if the message is deferred by the receiving server, and a bounce event if it eventually bounces. Now, we’ve added delivered as confirmation that the receiving server has responded successfully.

When syncing members in bulk via the Lists endpoint, tags are now properly added to existing members. If you would like to completely replace the tags of a member with the tags being passed in the request, we have added a new boolean param sync_tags, which will cause the call to replace any tags on the existing member. This will only work when making the call with updated_existing set to true.

Previously, when updating members in bulk via the Lists or Members endpoints, tags would not be added to an existing member. There was also no way to overwrite the tags completely.

We now allow a user to submit up to 500 pending API batches. For each completed batch, we send those results to each batch webhook that has been created. A user will not be able to create more API batches if there are 500 outstanding batch webhooks that have yet to complete. A 429 status code will be returned in this instance.

Previously, we did not have a limit on how many batch webhooks could be instantiated for a given user. This unbounded nature can have an impact on the performance of the API, which this new limit will help mitigate.

In the past, our implementation of Handlebars did not support camelCase, so all variables had to be written using all lowercase letters or using snake_case. Using camelCase for variable names is now supported.

A large portion of developers using the Handlebars templating engine are used to the JavaScript convention of writing variables in camelCase.

​​We fixed an issue that was causing the Rejection Denylist page to appear as blank.

Expired entries were appearing on the Rejection Denylist page, which pushed out active entries and made the list appear empty. Now only active entries appear.

We’ve created a new Stripe plugin, api-plugin-payments-stripe-sca, and we recommend that all users of the existing Stripe plugin migrate to it. api-plugin-payments-stripe is now deprecated and will be supported until October 31, 2021. This release also affects the example-storefront repository, which now includes components to support 3D Secure validation.

Thanks to contributor Janus Reith for his input.

The new plugin is designed to comply with the current Strong Customer Authentication (SCA) regulation, part of PSD2 regulation in Europe, which requires changes to how your European customers authenticate online payments.

We’ve added a new series of Allowlists endpoints that are functionally identical to the Whitelists endpoints, but use new inclusive terminology instead. 

In an effort to move towards using more inclusive terminology in our application, we’ve changed all instances of the terms “blacklist” and “whitelist” to “denylist” and “allowlist,” respectively. There may still be lingering uses of the old terminology in API responses or webhooks; please know that we are working on retiring all instances of those terms.