Webhook retry interval increased
What
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.
Why
Increasing this interval gives users more time to troubleshoot their webhook endpoint, and retains the webhook payload for longer.
- February 12, 2024Action Required
Updated Mailchimp Transactional client libraries
TransactionalWhat
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.
Why
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 theX-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. - June 5, 2023Action Required
Retiring legacy versions of Transport Layer Security (TLS) protocol
TransactionalWhat
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.
Why
TLS v1.0 and v.1.1 have been sunsetted so we are making the corresponding changes.
- December 19, 2023Action Required
New sending domain authentication requirements
TransactionalWhat
Beginning on March 15, 2024, we'll be enforcing new sending domain authentication requirements that you'll need to act on.
Why
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 valuedkim1.mandrillapp.com
, and another with the namemte2._domainkey.
yourdomain.com
and the valuedkim2.mandrillapp.com
DMARC
Create and save a TXT record in your DNS with a name of
_dmarc.
yourdomain.com
and a value ofv=DMARC1; p=none
Replace
yourdomain.com
with the domain you're setting up. Some domain hosts automatically addyourdomain.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.
- June 17, 2023Action Required
Response code updated for invalid template name
TransactionalWhat
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.
Why
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.
- July 3, 2023Action Required
Changing API server response for client errors
TransactionalWhat
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.Why
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. - June 1, 2023Action Required
Export API 1.0 and API 2.0 no longer supported
MarketingWhat
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.
Why
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.
- April 14, 2023Action Required
Changing messages/info server response
TransactionalWhat
We’ve been updating our API responses recently to provide a more semantic response for the requests you make. With this release, our servers will respond an HTTP 404 Not Found if you provide an invalid message ID when requesting message information.
If you’re specifically targeting HTTP response codes other than 200, you may need to update your code.
Why
Previously, we responded with an HTTP 500 Server Error when you provided an invalid message ID. We’re updating this to bring our response in line with proper semantics and allow more efficient status monitoring.