Constant Contact’s insane API downtime practice

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.

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.