Is the API currently down / broken?
My custom wrapper that was 100% working is no longer working.
Making an API call to http://api.createsend.com/api/v3/countries.xml or https://api.createsend.com/api/v3/countries.xml are both returning a 200 OK response header, but the file content just has 'Connection Failure' in it.
Hey Jonathon, is this still a problem for you?
Can you just try testing those routes in you web browser? I do not see many API errors from around the time you posted this.
When did you notice the first instance of your API calls failing? If you contact support with the API key you are using, we can look up the logs specifically for your API calls.
We've checked the logs of your countries API calls, and the raw response we've been sending back looks fine. We also notice that you're using Cold Fusion to make these API calls. Is that correct?
Putting the raw API call in a browser using your API key works for us. You could try it yourself using your web browser with the following URL:
Just be aware that depending on what browser you use, you may need to View Source on the resulting page to see the returned XML.
If that browser call works for you, then it would seem that Cold Fusion is the problem. We do not have Cold Fusion expertise in house, so I'm afraid that in that case we cannot help you much further.
Please let us know if you have any further questions or problems.
Still getting this issue unfortunately. My custom ColdFusion wrapper was working fine and was in use on a clients site (different API key) and now that is also getting the 'Connection Failure' message for all API methods and i've not made any changes to it.
Have you made any changes on your end to the API. Any request headers or anything like that?
I believe you've already talked to Mark via support. Did you rule out any problems processing responses which are compressed using gzip?
If you aren't already doing so, I'd suggest ensuring that you include the Accept-Encoding header in your requests with a value of "gzip", as well as ensuring that your code (or the library you're using) is processing the gzip-compressed HTTP responses correctly (responses should contain the Content-Encoding header with a value of "gzip").
More details on gzip encoding are here: http://en.wikipedia.org/wiki/HTTP_compression
More detail than "Connection Failure" for your specific error would be useful. I believe Mark couldn't see evidence of any errors occurring on our end, which would lead me to suggest this problem may be due to the way you're processing responses.
Don't hesitate to follow this up with support, where we'll be able to look up our logs for your specific API requests.
oooh, that problem again. That was an issue that existed with the V2 api & coldfusions cfhttp.
Have you recently enabled compression for API V3?
The code worked without decompression fine until recently.
Will add the necessary changes tonight and see what happens :)
gzip compression was enabled on API responses a while ago, however responses should only be gzip-compressed if you ask them to be, by specifying the Accept-Encoding header with a value of gzip.
If you are specifying the Accept-Encoding header with a value of gzip in your requests, your code processing the response should obviously be able to handle gzip compression.
So it isn't an "issue" with enabling compression on API responses. If the problem you are experiencing is being caused by you requesting gzip-compressed responses and not processing them appropriately (or using a library which is doing this incorrectly), that is where the issue is.
My wrapper hadnt specified any encoidng headers, but by adding:
<cfhttpparam type="header" name="accept-encoding" value="no-compression" />
to my code, the file content is now readable.
Thanks for your help.
From Australia to Zimbabwe, and everywhere in between, companies count on Campaign Monitor for email campaigns that boost the bottom line.Get started for free