So – I am going to caveat this whole thing with – if you’re not interested in using the API or you are not coming from another service with an existing API integration, this probably won’t apply to you.
Summary: 2 different API’s, both awfully designed, both poorly documented, both with completely different authentication methods, credentials etc. however, the application itself is great, so if you’re not using the API, it’s probably fine.
SendPulse has a functional API, but it feels like it was created by someone that read a REST API book of best practices without really thinking about how people would / should use it.
My biggest problem is the way authentication works (on the main API which is for sending your campaigns, managing subscriptions etc.), sure it follows all OAUTH standards, but this means you need to manage identify on your application so you send all the correct tokens etc., it feels very Salesforce, not Slack (if you have used either of these API’s you will know, Slack is easy, Salesforce is really really hard) – another comparison would be that it feels like IBM made this software when you are using the API, not a start-up.
If you are coming from something like MailChimp – the MailChimp API is easy, send a request with your API key and whatever you are requesting happens or you get a meaningful response, I have seen many garbage responses from the SendPulse API – you cannot guarantee JSON will come back, sometimes you get HTML, sometimes you get a weird HTML 404 page with some Yahoo copyright notices all over it, it all depends on how mangled your request is – so on top of having to worry about handling identity, you need to handle all sorts of strange responses not just JSON – and therein lies the next problem – DOCUMENTATION:
The API documentation is god-damn-awful, and because the API is quite complex and / or obscure in terms of how you request stuff, you often end up with garbage responses and have to trial-and-error how stuff works.
SendPulse has created a bunch of libraries to make this easier, and if you want to hang your PHP application by using their library, then go ahead – but if you have some kind of background task manager you will probably have to write your own stuff, which in most cases would not be too hard, but because the documentation is sparse, I really struggled to do even the basic stuff with CURL on the command line – if I was to suggest anything, provide CURL examples like Slack does, at least that way I could reverse engineer the CURL to sort out the lack of actual documentation (again, it’s a problem because the API responds with junk HTML if you get your request wrong so you don’t know what is actually wrong and have to trial-and-error a lot).
On top of all of this, if you are planning on using the SMTP send-alone API, you have a completely different authentication process – one that I still have no idea how to make work – this is what the documentation says about how to authenticate: http://i.imgur.com/sVAc3II.png
(the original documentation is here, but I think you need to be logged in to view it: https://login.sendpulse.com/manual/smtp-api/)
I personally have no idea how to authenticate against this SMTP API. I have not yet asked support about it because they are looking at something else for me that is more important, but I just don’t…….. what….. from the documentation (a required parameter to authenticate, IV): “iv – an initialization vector, encrypted by a public key with an OpenSSL Library usage” – what is this? Why is it never mentioned again? how do I get it?
And most importantly, why on earth is it different to the (already convoluted) other OAUTH authentication on the main mail API?
Anyway, to wrap this up, I picked up SendPulse because I needed both templated / campaign based email and SMTP / transactional email and I previously had MailChimp, but did not want to pay for Mandrill because my SMTP volumes were super low.
SendPulse is fine, but I have wasted more time than the money I would have saved just using Mandril, however if you can get over all of this, the product is actually pretty good which is why I have not left a steamer of a review score, and as I said at the start, if you are not using the API it is great.
I just hope they release a new version of the API that focuses on functionality rather than horrible REST standards (although I’m not convinced all of this is standards compliant), which I think have generally been thrown away by the new-wave tech start-ups so people can quickly deliver value.
Can't use Email Builder emails in the SMTP email interface
Value for money
Ease of use
Likelihood to recommend: 4/10