Constant Contact’s insane API downtime practice

Filed under: Rant,Web/Tech | 1 Comment

Constant Contact is the leading email newsletter company and hundreds of thousands of businesses use their service to send marketing emails to customers. Constant Contact is a lot bigger than most people think, they are even a publicly traded company with a half billion dollar market cap. However, money can’t buy sanity.

Constant Contact is typically used through a web interface, but they do provide an API to allow some basic functions to be handled remotely. It’s a pretty limited API (you can’t even send email through it!), but that’s a rant for another day. All I’m using it for is adding contacts and basic list management. Simple stuff.

I’ve had a lot of problems with reliability in the past, but last night takes the cake. Constant Contact had a scheduled downtime for the API that resulted in all requests returning a 200 OK HTTP status code and an HTML page explaining the issue. If you tried to search for a contact, you got the page. If you tried to add a contact you got the page. Etc. But the 200 OK status code makes it look like the request was processed correctly and this HTML was the response (which should be XML if everything did go as planned). They’re using a browser error screen for API responses… Insane.

Constant Contact API downtime error page

Why return an HTTP 200 OK status code when it’s most certainly not OK? How is my code supposed to know that when you say everything is OK and here’s our response that you really mean “our shit’s off, we’ll be back soon”? A 503 Service Unavailable seems much more logical, but there’s a whole list to choose from. Almost every one is better than 200.

My code can figure out it’s not the XML that should be returned by catching the exception from the XML processor, but it shouldn’t have to. Also, I still need to get alerted to when this is caught because what if next time it’s not that there is downtime but something else that would require a change on my end? There’s no way to tell since it’s an HTML page returned and not a simple error code or message.

Even better is the HTML error message (for a service never designed to be used by a device that reads HTML) has a nasty JavaScript error that loops and eventually crashes Safari. Woo! Is there any possible reason for having JavaScript on a page that should only be read by computers? I’ve gotten a lot of errors back from various APIs and this is the first time it has been a HTML/JS page. And even then it crashes the browser. Fail.

Constant Contact API downtime JS error

Read the latest posts

One Response to “Constant Contact’s insane API downtime practice”

  1. Dan Richards says:

    Ouch! And you’re so right! Shame on us! Our apologies for not providing a useful end-user experience. We are still getting our feet under ourselves in terms of evolving from a strictly web UI experience to providing a robust web services infrastructure. I can assure you we are actively working to make sure we improve this for the future as we work to provide a much richer set of services as we go forward.

    Please do not hesitate to contact me if you have any questions and/or comments.

    -Dan Richards
    VP, Constant Contact labs

Leave a Reply to Dan Richards