We’ve increased the number of times that a webhook will retry when we don’t initially receive a 200 response. We will now retry up to 20 times, at intervals of 15-25 minutes per retry. After 20 unsuccessful attempts, the webhook will be disabled.

Increasing this interval gives users more time to troubleshoot their webhook endpoint, and retains the webhook payload for longer. 

We've published an updated package for the PHP client library that is compatible with PHP 8.2.

We've also published an updated package for the Node.js client library that uses the latest version of Axios to address a security vulnerability.

Older versions of the PHP client library caused errors when used with PHP 8.2.

A vulnerability was found in versions 0.8.1 through 1.5.1 of Axios, which unintentionally exposed the XSRF-TOKEN that was stored in cookies by including it in the X-XSRF-TOKEN HTTP header for all requests to any host. This allowed malicious actors possible access to sensitive data. To address this issue, we have updated the Node.js client library to use the latest version of Axios.

As of July 18, 2023, Mailchimp Transactional no longer supports Transport Layer Security protocol (TLS) v1.0 and v1.1. We already support TLS v.1.2 and above. If you're not using TLS v1.2 or above, this may require coding changes.

TLS v1.0 and v.1.1 have been sunsetted so we are making the corresponding changes.

Beginning on March 15, 2024, we'll be enforcing new sending domain authentication requirements that you'll need to act on.

Google and Yahoo recently announced new sending requirements that will go into effect soon. To comply with these changes, Mailchimp Transactional users will have to update their DKIM records and enact a DMARC policy on any sending domain that might be used. 

If you fail to update your domain’s authentication, we’ll use a mandrillapp.com subdomain as the sending domain for your email address, but replies from recipients will still go to your email address. This change will apply to any email sent through Mandrill that is currently authenticated but doesn't meet our new authentication requirements after March 15.

Here's how you can get started:

DKIM

Create two CNAME records: one with the name mte1._domainkey.yourdomain.com with the value dkim1.mandrillapp.com, and another with the name mte2._domainkey.yourdomain.com and the value dkim2.mandrillapp.com 

DMARC

Create and save a TXT record in your DNS with a name of _dmarc.yourdomain.com and a value of v=DMARC1; p=none

Replace yourdomain.com with the domain you're setting up. Some domain hosts automatically add yourdomain.com after the initial value—contact your domain provider for any specifics.

We’ve updated the Mailchimp Transactional app and documentation to include these instructions, and to give you the ability to test these records on your Sending Domains page.

We’ve been updating our API responses recently to provide a more semantic response for the requests you make. With this release, we’re changing the way our API responds if you provide an invalid template name when requesting template information or if you try to send a message using a template that doesn’t exist. Once this change goes live, we’ll respond with an HTTP 404 Not Found. 

If you’re specifically targeting HTTP response codes other than 200, you may need to update your code. We’re releasing this change incrementally over the next few weeks.

Previously, we responded with an HTTP 500 Server Error when you provided an invalid template name or slug. We’re updating this to bring our response in line with proper semantics and allow more efficient status monitoring.

We’ve been updating our API responses recently to provide a more semantic response for the requests you make. With this release, we’re changing the way our servers respond if you provide invalid or missing data when performing a request to our API. Once this change goes live, we’ll respond with an HTTP 400 Bad Request, indicating you will have to make changes to your payload in the subsequent requests. 

If you’re specifically targeting HTTP response codes other than 200, you may need to update your code. We’re releasing this change incrementally over the next few weeks.

Previously, we responded with an HTTP 500 Server Error when you provided an invalid or missing payload. We’re updating this to bring our response in line with proper semantics and allow more efficient status monitoring.

We retired API Export 1.0 and API 2.0 on June 1, 2023.  We won’t support calls to these endpoints after the retirement date and will return an HTTP 410 status message. If your application or integration still makes use of these endpoints, you’ll need to update it to our Marketing API 3.0.

We deprecated API Export 1.0 and API 2.0 on December 31, 2016 and have encouraged our developer community to upgrade to API 3.0 in the intervening time. Although we've continued to support the deprecated endpoints, they've seen increasing performance issues and it’s no longer viable to maintain them.