There are some providers I always find myself having an issue integrating into my applications. PayPal is one (ugggh, PayPal) but Mailchimp is another. Everytime I have integrated Mailchimp I find myself coming up against certain problems, so I though I'd get them written down.
Here I'm referring specifically to the member/put/ API endpoint.
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.
I haven't seen this issue for a while but in the past I 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.
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.
I've used the Mailchimp.Net.v3 package before now and found it pretty easy to implement annd always assumed that any issues I've had have been with the API itself not the client. However, I 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, I 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 my case, I created a static class which had a static property defining some default serialization settings I could use as and when I needed them, leaving the gloab settings to remain as the out-of-the-box defaults.
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 fpr each request so this could be very costly if you are doing a lot of requests to the Mailchimp API!
Tags:
Mailchimp
,
JSON
,
Serialization
,
Integrations
,
Configuration
Published: 15 January 2019