Mailchimp Developer LogoMailchimp Developer Wordmark
June 17, 2024

Webhook retry interval increased

Transactional

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

    Transactional

    What

    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 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.

  • June 5, 2023Action Required

    Retiring legacy versions of Transport Layer Security (TLS) protocol

    Transactional

    What

    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

    Transactional

    What

    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 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.

  • June 17, 2023Action Required

    Response code updated for invalid template name

    Transactional

    What

    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

    Transactional

    What

    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

    Marketing

    What

    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

    Transactional

    What

    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.