Lessons from Failed DocuSign Integration

It's not really a bug though. It sounds like DS shows a dashboard for the user absent an instruction to show a different page. That's a reasonable default.

>A sophisticated enough client user would still have access to the all data associated to the API user.

If you use one account to access an API then of course it's your responsibility to control access. How would the API provider be able to do that?

Some notes:

* Their API documentation really is garbage. If you're signed in to your developer account, you get access to marginally better documentation. This makes it hard to abuse Google to find things you're looking for. Specifically, the documentation is incomplete and difficult to navigate, largely because they appear to have relied on Swagger to generate the whole mess.

* Their support sucks, and exists mostly to try to get you to pay for their team to write code for you to interact with their code, rather than fixing their documentation.

* The API has some warts. I wouldn't care about the warts so much if the documentation compensated for it, but it doesn't, so I've burned lots and lots (and lots) of hours trying to figure out the weird bits. For example:

> You specify the difference between an "embedded" and "remote" recipient by setting a clientUserId attribute;

> But, if you specify both a clientUserId and a client name attribute, then the API call to createRecipientView will probably return a "User not found" error (see for example https://stackoverflow.com/questions/20500630/unknown-envelop...

> You send an envelope not with an API call like sendEnvelope, but by setting the envelope status to "sent";

> Exceptions thrown during the authentication process by default set the Exception's error message to "Error connecting to the API...". Guess how much fun that was to debug?

* And their library for PHP is really a steaming pile. It's just a wrapper around curl, auto-generated by Swagger. It pretty much demands a wrapper around their library to be able to work with it effectively and compensate for all the warty bits.

I haven't quite got to the point of hating Docusign, but I don't love them, and wouldn't recommend them to other developers. I did find HelloSign early on in this project, and their API documentation (https://app.hellosign.com/api/documentation) is everything that I wish Docusign's was, and they clearly make a much greater effort to be attractive to developers.

I'd love to link some of the Docusign support articles and such I've filed under my "docusign_sucks" tag, but you need to be signed in to your Docusign developer account to view them...

Docusign is indeed pretty terrible as an API, but it does have the benefit that users have heard of it so it has a certain institutional credibility - which is usually important if you're developing the sort of app that needs an e-signature process. On that front, all of our clients were very comfortable with Adobe as a secure service provider - it was something we publicized, in fact.

I've played a bit with Hellosign. While I've heard they have a nice API, they don't have the institutional credibility that Docusign and EchoSign have. Also, their pricing was way, way higher than EchoSign's, in my experience. I'd love to learn more about them, though.

After you click on a search result and are served a webpage not owned by Google, Google can't control what happens if you press the refresh button.