There are some providers we always find myself having an issue integrating into my applications. PayPal is one (ugggh, PayPal) but Mailchimp is another. Everytime we have integrated Mailchimp, we find ourselves coming up against certain problems, so we thought we'd get them written down.

Here, we're referring specifically to the member/put/ API endpoint.

1. Case sensitivity

The merge field names are case sensitive. It might seem obvious to some but if you're serializing your JSON before posting/putting it to the Mailchimp API, then you may find that it's being rejected even though the data is present. If you're using a camelcase formatter, then this will alter the case of your merge fields and Mailchimp will reject this if the field is required.

Where the field is not require, the data will just be ignored and no error message will be returned. Great.

2. Field order

We haven't seen this issue for a while but in the past we have found that providing a JSON call with the merge fields in a non-numerical order, then it would be rejected. For example, speifying MMERGE3 before MMERGE2 would result in the data not being saved.

3. List deletion

Recently in a support ticket thread it was revealed that a list that we were creating new members in via the API, was internally marked as deleted. However, the API did not prevent saving data and as a result only partially saved the data being written to it.

4. Mailchimp.Net Serialization

We've used the Mailchimp.Net.v3 package before now and found it pretty easy to implement and always assumed that any issues we've had have been with the API itself not the client. However, we recently had the issue mentioned in point #1 and was etting nowhere with Mailchimp's support team. It turns out that yes, the data being submitted from this package was serializing my data and altering the case of the fields - based upon my applications global serialization settings.

Given that Mailchimp's API has restrictions around case sensitivity, we expected the package to ensure that these were adhered to by overriding the serialization settings per request but under the hood, the client uses HttpClient.PutAsJsonAsync() which uses the current application's global serialization settings.

The answer is obviously for Mailchimp.Net.v3 to use HttpClient.PutAsync() and pass default serialization settings as a parameter. But whilst this update is pending (or not), you should avoid using global settings or reset them on a request by request basis. In our case, we created a static class which had a static property defining some default serialization settings we could use as and when we needed them, leaving the gloab settings to remain as the out-of-the-box defaults.

5. Mailchimp.Net.v3 HttpClient usage

Another issue with the use of the HttpClient in the Mailchimp.Net.v3 package is that a new instance is created for each request that is made via the package. This needn't be a problem but it has always been recommended practice to use a single instance of the HttpClient through the application in order to avoid exhausting connections. Mailchimp.Net.v3 spins up and disposes of a single instance for each request so this could be very costly if you are doing a lot of requests to the Mailchimp API!

Et harum quidem rerum facilis est et expedita distinctio

Browse content

Dealing with Mailchimp.Net gotchas