Hacker News new | past | comments | ask | show | jobs | submit login
Lessons from Failed DocuSign Integration (profsmallpine.com)
155 points by profsmallpine on Jan 24, 2019 | hide | past | favorite | 79 comments

I was on this project and can speak a bit more on the technical details here.

A couple of high level goals:

1. We wanted to use their embedded flows, to keep the experience within our application as much as possible.

2. We wanted to avoid having to create a DS user for every user in our application that turned on this feature. We were looking for using 1 “API user” to make requests, handling data scoping ourselves within the application.

The actual issue in more detail:

1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page)

2. Refresh the page

3. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data).

At this point (as the OP called out), we realized we had no choice but to create DS users. But we still wanted to hide this process from our users, keeping DS as embedded as possible. The issue was their “regular” user creation flow involves a email going out to the user to confirm - obviously this is unideal if our goal was to wrap DS and hide it’s existence as much as possible from users.

DocuSign offered a workaround for this, which involved basically getting shifted to a legacy version of the API, with no hard promise of it not being sunsetted. By then, we had had such a poor experience with non-answers from their team that we called it quits.

I hope this clarifies some of the technical problems we were trying to solve for.

Edit - I'm sure DocuSign can solve for some use cases. Obviously, they have a large user base and I'm sure most of them are at least satisfied, if not happy. But if you're trying to wrap an e-sign provider within your application, I would recommend HelloSign 1000x. HelloSign's API is a first class citizen whereas DocuSign's felt more like an afterthought.

I'd like to add a little more to this - our main frustration isn't necessarily because of these technical difficulties. Communicating implementation details and 3rd party integrations can be challenging, especially if one side of the convo is not super technical. That is totally understandable, and probably inevitable.

The main reason this felt so...sucky for lack of a better term, is that we had multiple discussions about our use case and were told that this would be supported (again, this turns out not to be true? not a huge deal, it happens), and were asked to pay $20,000 upfront of which we got $0 back once realizing the original promises were not true.

As OP pointed out, 20k for a huge company like DS might not seem like much, but for a small start up like us it is. Just from a consumer perspective, this seems like a crappy way to conduct business.

Sounds like the - unfortunately very common - thing where sales people make promises which aren't delivered on.

Seems to be the sales people doing this get bonuses regardless, even though the customers get shafted, and their own tech staff generally get shafted too. :(

I once worked at a company that dealt with DS. Rumors where that we paid more than double that amount. The integration never really took off, so in the end, it was a huge waste of money.

We did exactly this integration, it was fairly seamless. I walked a Jr dev through the high level plan and we cooked up a POC in postman in about an hour that did a very rough bare bones version of what we were looking for. He was then able to run with that rough POC and build a production service that managed all of our docusign integration. I wonder what caused us to have such different experiences with the API.

You have definitely struck my curiosity - which version of this integration I outlined did you guys implement?

1. Embedded views + user creation w/o requiring email confirmation

2. Embedded views with 1 API User

I don't want to assume anything here, but I think you either didn't build exactly what we were trying to, you are on the legacy version of their API, or you have that embedded view refresh bug I outlined live in prod.

I just checked we are using the v2 rest api. We create a user, we do not send them an email, we then add the documents and setup the envelope, then direct them to the user's embed signing room.

I wish I could find the old postman POC since that would make it a lot easier for me to explain exactly our sequence of api calls.

We use v2 API as well and like rblatz said, we haven't ran into any problems.

Our backend signs in to DocuSign as the main account. When a particular event requires it, the backend sends a POST to DocuSign and creates an envelope. In this POST request, we tell DocuSign that the user is going to be an embedded user. Once the envelope is created, we can ask for the "view url". In this request, we not only tell DocuSign to get us the vie URL for a specific signer (in case there are multiple signers), but we also tell DocuSign where we want the user to be redirected to after they are done signing. When this request returns, we will have a URL that we can redirect our end user to.

Also, in terms of their documentation, I think it is fantastic in it thoroughness.

All in all, I've had the opposite experience of OP.

This is exactly how our integration works, as well.

It’s an esignature application. Of course by law you have to create a Docusign user for each record holder.

You may come and go bankrupt but your customers have to hold their own contracts on file for the life of the contract plus N years depending on their jurisdiction (eg 7 years).

Law citation please? To be more clear, I've just signed documents via docusign and did not have to create an account. Perhaps the system behind me did something to create an account for my email address without my consent, but I don't have a 'docusign account' in any meaningful sense.

When I read retrospectives like this, I wonder how many apps have this bug and don't know it.

>1. Go to an embedded page, authenticated as the “API user” (which looks like you’re sandboxed within DS to the embedded page)

>2. Refresh the page

>3. You now can click around the entire account - viewing any data that belongs to the API user (in our case, all of the data).

I don't quite understand this. Shouldn't you be able to control what is displayed during the refresh?

No, their embedded view is hosted on their site. The functionality is directing to them to a page on their site, with a redirect URL to our app after they are "done" there. This allows DS to be embedded into app-side workflows.

>No, their embedded view is hosted on their site.

Right, but aren't you telling them which view to show? For example, show document X for the user to sign.

Yes. The problem is that on page refresh, that constraint is lost and the user is logged into the account, in DS UI. They can click around anywhere at this point, outside of the page we specified.

I'm curious as to how HelloSign guards against this. Do they have some sort of session token that sends you back to the signing page on refresh? (i.e. similar to guard to avoid submitting shopping cart purchases twice).

HelloSign's embedded signing happens in a iframe, through their JS client. The user is never directed to HelloSign's site unless you choose to to an un-embedded workflow.

>The problem is that on page refresh, that constraint is lost

Why can't you put this constraint in a session and pass it back in on refresh?

View 1 is on the DS domain. We have no control once the user is in there aside from giving the redirect URL.

This is the point where someone is extremely confused but I'm not sure which one of us it is.

My understanding is that you have a page at the end of some process for the user to sign a document. The first time the user goes to the page they see the screen to sign something (View 1). They refresh the screen. Now they see some dashboard like screen where they can see everything (View 2).

Is that not right?

1. We want the application user to sign a contract.

2. We request an embedded signing url from DS (we provide authentication creds, as well as redirect url as params - what we get back is a "special" url on DS. E.g. it is docusign.com/blahblahblah)

3. We redirect the user to the special DS url.

4. If the user signs, or refuses to sign or w/e, the user will get redirected back to our application via the redirect url we provided in our request on step #2. If the user instead decides to refresh the page, they for some reason are broken out of the signing page, and can now do whatever they want in the account as they are logged into DS's site for some reason.

So you're not embedding the DS page in your site. You're redirecting the user to DS?

I understood it as they were using the API for validation but loading the embedded content straight from DS, in which case they wouldn't be able to control whatever's displayed in the embed.

A user goes to a page and sees DocuSign view 1. Now they refresh and see DocuSign view 2 that shows everything. How did they get they get view 1 and why couldn't they do it again on refresh?

View 1 comes from us (see my reply to your comment below). As for your 2nd question - that is the crux of the problem we had.

If View 1 comes from you why can't you give it back to the user on refresh?

From my understanding, thier application redirects to a webpage that DocuSign owns (which ideally redirects back to the original website). Once the user is on some DocuSign.com webpage, you have no control at all over what happens.

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.

Even if they added this feature, the API bug would still remain (it would just be covered up by the UI).

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

>Even if they added this feature, the API bug would still remain (it would just be covered up by the UI).

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?

I think the part that you may be missing is that View 1 (embedded view) is hosted on DocuSign's domain.

So the view may be designed by the client, but it's not hosted by the client. It's hosted on DocuSign.

Then View 2, is the "dashboard" view which of course isn't designed by the client.

In an ideally designed embedded View 1, it should not be possible to get to DocuSign's "dashboard" (View 2). Sessions should be tracked in DocuSign's API and View 1 refreshes should return the user to hosted View 1 or should return an error.

I thought OP was embedding something from DS in their page. It sounds like they are redirecting a user to DocuSign.com. I agree that the user being able to access the requester's DS is a massive security issue. So massive that it seems implausible that it actually works that way, but I don't have any experience to know one way or another.

Were the contracts user generated, or your own standard template?

If the latter, then embedding your own signature tags into a standard template seems like the simplest use of DS API.

Wondering why their tech support didn't share this solution. Or maybe it's no longer supported(?)

(Full disclosure: I helped design the DS REST API and their Salesforce AppExchange app many years ago)

Users (our app users) would have created their own templates and used them for sending envelopes.

In my experience, most APIs requires a 1-on-1 association between the application's user and the API user (if some information about the user, and associated records, are stored in the external service).

Maybe the goal here wasn't to be technical (although I'm not sure why given it's an article about docusign api integration) but this is a WHOOOOOLE lot of text with basically nothing worth reading.

>I was annoyed that they didn’t provide a secret key to authorize API requests

Yeah... they don't do that for a reason. They appear to support a fully fledged OAuth implementation (https://developers.docusign.com/esign-rest-api/guides/). I haven't used it, so maybe it's terrible, but I'm suspicious of the author at this point.

>DocuSign API docs are very quirky

But no discussion of why, or what he would expect instead. This actually sounds like the author is lost because they don't understand OAuth again (and to be fair, I've implemented OAuth and it's easy to get wrong).

>Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request. [...] About a week later, we were informed that this is intentional, and they were worried about breaking anyone that is using this as a feature.

This honestly sounds like they were politely telling you that you haven't implemented OAuth correctly. You should be making the request with the token of the delegated user, not a generic account.

>I got this working, but it took some janky work to re-work the JWT flow to manage hourly expiring tokens for all of our user that choose to enable the esignature feature.

This is what refresh tokens are for. I highly doubt the refresh token expired in an hour, but hey - I haven't used it so maybe I'm wrong.


I honestly believe I can summarize this whole article as: Dev takes first steps into OAuth and gets lost...

OAuth is going to be hard to use if you don’t create an account though, there’s no way for DS to know what scopes to restrict the user to, it sounds like that was the core issue that broke their workflow.

I think it is very unclear what is real and not real. OP is mostly passing blame to DocuSign without achieving full understanding themselves. That is more an indictment on OP than DocuSign even if there is some actual session security problem with DocuSign (likely from the deprecated API).

>>I think it is very unclear what is real and not real. OP is mostly passing blame to DocuSign without achieving full understanding themselves.

To be fair, it is difficult to achieve "full understanding" with such garbage documentation as DocuSign's.

Yeah and it sounds like they were trying to do something that makes no sense for DocuSign to support: use a single account to sign all users’ documents.

DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account?

They support oauth and that makes sense and should be the way to do it.

DocuSign should've recognized this and let them know the flaws in their plan, but in my experience they're _way_ too sales-oriented to ever do this.

I had a similar experience. I explored their API and got stuck on how to implement my use-case and how to ensure it's legally binding. Sales and "technical" resources assured me it was possible, didn't explain how, and everyone balked at any sort of legal questions and basically told me that was all on us to sort out.

I decided I didn't need help creating a box for users to scribble on. E-signature isn't a technical challenge at all.

>DocuSign has a legal obligation here to prove authenticity, how are they ever going to be able to do that if everything is behind a single account?

By the signature.

I don't know how it works in DocuSign's internals, but there's no requirement for the signer to have an account. The point of the account is for users to see all of their documents in one place. In OP's case that's everyone's documents because they use a single account.


Yep. I just signed things via docusign 2 weeks ago. There was no 'create an account' first. IIRC, there was something at the end indicating I could create an account after the doc was signed, but I got a copy via email anyway which was all I needed. The last thing I need is yet another account/login for what is essentially a one-time thing.

I had a project that used docuSign a few years ago. There were some very strange things going on with their API.

I remember having to call them asking where to find a template ID so I could save that and send out the proper doc to customers. It was not listed anywhere on the developer dashboard. The rep told me in a very condescending way that it template ID was part of the URL. I should have known to just use that!

My app was written in a python backend. They had a some API examples in different languages for their docs. The python example was a total embarrassment. It was clear that the person who wrote it had no experience with python at all. I am not trying to be mean, it was that bad. Every line ended with a semicolon (in python this is not an error, but is officially discouraged). The person also seemed to not be aware of a dictionary. They built their json paylod by concatenating text. It was the messiest python code I had ever seen. I think this particular bit of code is gone now, but it was incredible.

I felt so bad that I emailed them some suggested fixes and asked if they had python experience. They responded with a something along the lines of ya, we had the java guy do that. But the code stayed up there for a long time...

I also worked on a Python project that integrated DocuSign.

I was able to hack together solutions and skirt around DocuSign's many problems, garbage documentation, and general very-low-quality API, but in no circumstance would I ever recommend it to anyone. Late in the project I seriously considered throwing it away and switching to another API.

The other API I considered was: https://app.hellosign.com/api/pricing

This is literally ten times the price of DocuSign and I don't know how long they'll be in business, so it's a hard sell to buy into that. The API docs looked way way better (like stripe or twilio or slack apis, rather than some janky enterprise nonsense), but development and hacking around DocuSign was a one time expense, and the API is an ongoing cost.

If remotely possible, I'd just sign stuff in person and mail or fax it, since all this stuff just adds difficulty, complexity, and cost, to very little benefit unless you have a LOT of people signing stuff. The application I worked one was for one or two signatures a month, so not worth the trouble.

I've done a docusign implementation, and I don't really agree with them. Their API is fine honestly, I think their documentation could be better and some things are named awkwardly. But the implementation really isn't hard, my only real complaint is that when we did it they pushes the DocuSign connect service really hard, which honestly was kind of a waste and didn't live up to many of their promises, but that's normal b2b upselling. It's a normal API, and definitely not as bad as this person makes it seem.

Whether an API is "good" or "bad" often is dependent on the requirements of the calling client. At the beginning of projects when client requirements are unclear, it is often hard to determine whether a supporting API/library truly meets your needs.

That is true. To move away from language like good or bad. I would say DocuSign is quite reliable, we had one outage that was their fault and we were an edge case. I would also say that their API is sufficient for 95% of use cases or more with very little work arounds. Their customer success architects or whatever they call them were also pleasant to work with and responded promptly.

I am DocuSign’s Lead Developer Evangelist. Thanks to Joseph (OP) for writing this up and to everyone who has contributed to this thread including both the positive and negative comments about integrating with DocuSign.

The problem OP ran into is really one of documentation and not a bug or security issue.

I agree that our docs for the embedded sender view should clearly state that the method’s URL gives full access to the sender’s account, and we’ll fix that ASAP. As others have commented, the assumption of this API method is that each sender has their own account. I also agree that the OP’s use case, which requires that the sender view’s capabilities be strictly limited to the current envelope, is valid. It is under consideration for our roadmap.

A workaround: I recommend that API applications complete the sending process programmatically including document tagging, etc. This also provides the best user experience for the sender.

We actively monitor and reply to the “docusignapi” tag on StackOverflow (I’m “Larry K”), if you want to reach out to us there.

I also agree that the OP’s use case, which requires that the sender view’s capabilities be strictly limited to the current envelope, is valid. It is under consideration for our roadmap.

If this case is valid, other customers besides OP are doing the same thing. They probably have the same vulnerability. It's also not clear how document tagging can stop this hole. If there is just one user then that user's users can't have that user's creds. Rather they must be limited to specific tokens that give them access to their specific documents.

>The problem OP ran into is really one of documentation and not a bug or security issue.

I'm confused about this. If I am given a link for a DocuSign I can gain access to the sender's account by refreshing the page?

> The problem OP ran into is really one of documentation and not a bug or security issue.

Thanks for admitting fault. How about:

a) Refunding them, as they requested.

b) Creating a follow up post and submitting here to HN when the docs are actually fixed. After all, the article itself describes many instances of them being told things would be fixed. Your doing so here on HN will be regarded the same way. eg by actions rather than words

Looking at the API description (very detailed BTW) https://developers.docusign.com/esign-rest-api/guides/authen... , it does look like they used a wrong flow for the use-case, and then invented some shortcuts to make it work (which understandably did not work out well).

It does look like onboarding failure, but there is so much you can do to steer the customers towards the right path. I am not completely convinced that this was Docusign's fault.

FWIW, I've developed a lot of this sort of tool. For some reason, Adobe E-sign services (formerly known as EchoSign) rarely comes up, but it's actually quite good and cost-effective to develop with.

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.

Saw this article and was familiar with the headaches of esignatures. HelloSign is very pretty but I've been using Adobe Sign for years now. When we had to switch from Business to Enterprise (I don't remember what limitation required the upgrade but it was business critical - edit: ah yes, I remember being able have a clickable link that generated a new one for each person). There was some friction because the support and people working on it seem to be handled by a different group of Adobe. There were two different logins, kinda weird. Couldn't sign up through the site and had to do a manual contract. After dealing with the technical team the migration worked and all is well, very nerve wracking time thinking you lost all your contracts. We had backups but still.

Anyways, one of the biggest issues with other services was the max amount of templates imposed by HelloSign and the rest. It feels very arbitrary yet Adobe can handle this at scale very cost effectively.

The UI needs work and some quality of life changes need to happen. I feel like it's been somewhat abandoned after the acquisition. If I need to edit a template with one tweak I have to completely redo the entire contract/document which is time consuming especially on multi-page contracts with tons of fields of different types.

We're married to it now and it does work but I would love to see enhancements or have Adobe at least get a few new designers and UI/UX people onboard.

Can you give any guidance on Adobe/EchoSign's API pricing? Seems like it's behind a "contact us" enterprise plan these days? https://acrobat.adobe.com/us/en/sign/pricing/plans.html

It generally seems ridiculous to me that it's 2019 and APIs like https://app.hellosign.com/api/pricing are priced per signature request. Even if each finalized signature comes with regulatory retention requirements, that's far from a linear cost... and these are PDFs we're talking about retaining, not videos. The whole ecosystem reeks of price fixing.

Yeah, there's little I hate more than opaque "contact us" pricing. To my surprise when I inquired EchoSign was actually much cheaper than the alternatives. At the time, I had an API license from EchoSign that cost a few hundred dollars a year for a very large number of monthly document signings, with no hard limit (but polite requests to buy additional licenses if you went above the limit). I don't know if they've kept this pricing model though.

Advice: Skip straight to the situation paragraph as anything before that isn't about the DocuSign integration, not sure what the first section brings to the whole article.

This is the third entry in the blog. Author just had some stuff to get off his chest. He might want to split this into two entries...

The author seems to have buried the lead here: "Someone on the team noticed that if you refresh the page, you get logged in as the user that was making the API request"

And that is how the implementation works for many of Docusign's customers as a 'feature'. If that's true, that would seem like a potentially exploitable security hole. However, I'd have to question if that had something to do with the particular implementation, otherwise I'd expect more focus on the security repercussions.

From what I can tell, the issue is that the OP was using a single user to perform all calls. They didn't want to sign users up individually, so they took this workaround route and found out that it wouldn't work after all. TLDR; they weren't using the API as intended because they wanted the DS part of the UX to be transparent to the user.

We just completed an embedded signature integration with HelloSign. The HelloSign API plans were expensive - but still a fraction of what DocuSign charged (at the time HS was 20% as expensive - pricing seems to have gotten more comparable now).

Integration was easy. The Ruby SDK & JS lib worked great (we have Rails back-end / React front-end). Customer service has been good & responsive. They have to approve your UI before giving live access - but once we had the integration working it took < 1 day to schedule the meeting, do the screenshare, and get approved.

Two slightly annoying things: (1) they don't have per-request fees if you go over your allotted usage. You'll get automatically bumped to the next plan which gives you 3x the request and is almost twice as expensive. (2) they wouldn't let us go month-to-month since we had an existing annual plan that we wanted to be under the same account (so we can share templates). This is tough since it's difficult for us to predict how many requests we'll need.

Just use HelloSign. Their developer support is the best I've had from an API company - you email them and you get support from an actual developer - and they smartly do things to save everyone trouble like creating an API debug console so you can see what they receive on their end. I wish all of our API partners followed their lead.

The best thing I can say about Docusign is that it is way, way better than Adobe Sign's absolute garbage support. The Adobe software may work but if you have the slightest problem with the API you will be in support hell.

All those online signatures "click to sign" services are useless anyway, they have absolutely no legal value anywhere (their EIDAS/ETSI whatever are just buzzwords), even in France from where docusign is coming.


In North Carolina, the "Click to Sign" services (such as DocuSign) must be licensed/approved by the North Carolina Department of the Secretary of State. An electronic signature from a licensed provider is just as good as a paper signature. They certainly have legal value and are used for real estate closing and the like.

NB: HelloSign, the other provider that's come up in the comments here, is not on the Secretary of State's list and is therefore worthless in North Carolina (and they're possibly in violation of the law for offering such services without seeking approval).

Secretary of State page listing approved providers (including DocuSign): https://www.sosnc.gov/divisions/notary/e_notary_solution_pro...

Electronic signatures are the same as paper signatures: https://www.smithdebnamlaw.com/2015/05/electronic-signatures...

Relevant North Carolina General Statute: https://www.ncleg.net/EnactedLegislation/Statutes/PDF/ByArti...

That article is pretty clear that the docusigned documents were invalid due to that specific court's rules.

To quote from the ruling [0] directly:

> Although DocuSign affixations and other software-generated electronic signatures may have a place in certain commercial and other transactions, they do not have a place as substitutes for wet signatures on a bankruptcy petition, schedules, statements, and other documents filed with the court, and they do not comply with this court’s local rule.

[0] (see page 7) : http://www.caeb.uscourts.gov/documents/Judges/Opinions/Local...

A real solution is a proper PKI - a great way forward would be if the US federal government issued citizens with X.509 digital certificates when they get their passport renewed: they’ve done the task of verifying identity, they just need to co-sign a cert and give people $5 smart cards with their $100 passports.

With state-sponsored PKI we can eliminate so many headaches and rockblocks in the digital economy and paperless government.

Given the whole SSN debacle and the low passport ownership in the US, I see this as functionally impossible.

We tried something similar years ago with DocuSign, and needed the ability to sign in person with two different people, one acting as a witness, with a potential third person being remote via email. It was not supported at all. Built our own internal system to handle esignatures, worked great, never looked back.

The article was a bit meandering (bit of a bildungsroman), but good to know to avoid docusign apis. Might have been able to find out how much it sucked just by googling more "docusign alternatives" or "docusign api sucks" =D

When we tried to bring docusign on board back in 2015-2016, it didn't feel like a very robust product in terms of user accounts management.

They had a legacy instance and a v2 instance (w/ new UI). Enterprise integration was against the legacy instance. Accounts created in one instance does not carry over to the new instance. User who self registered in new instance some how makes authentication into the legacy instance very difficult.

As a user with admin access to docusign, there were a paltry of user management features. I had to delete individual users. No way to filter or batch any user oriented actions.

We rolled our own bc out of box solutions were crazy expensive. Any one else do this? I'm kind of surprised how much people are willing to pay for something that is not that hard to build. You can't build your own twilio or Google maps but Hou absolutely can build your own signature feature.

I've been working a lot on a project recently with a fair bit of Docusign integration.

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...

> we’ve tried to build as much as we can as to skip dependencies, I’ve spent enough time in rails to appreciate debugging owned code - an argument for another time...

Okay, I'll bite. I have no experience in RoR, but does this line suggest that RoR encourages NIH?

This line feels like that scene in a horror movie, right at the beginning, when the camera lingers a little too long on the janitor's face as he cracks a smile that's wider than it should be.

Red flags:

* NIH (mentioned above)

* Using Go in production (more specifically, complaining about the lack of support for Go in production -- you should have known what you were getting into)

* Announcing a hacked-together MVP to the whole company

* Escalated to a VP for a technical issue

* Not using the company's recommended workflow, instead building your own

There's no way that the inability for the author to deploy DocuSign, an API that hundreds of companies successfully use, is on DocuSign.

Also, an maybe this is just a cynical view, but when you start your cautionary tale with a literal, "It all started when I was 11", it's kind of hard to relate.

Absolutely not on the RoR encouraging NIH side - there's a huge ecosystem of libraries to handle most of the day to day stuff, and because of the way Ruby works its really easy to stub out things like 3rd party APIs for test suites. If someone on my team tried to argue that they should implement the API client themselves rather than using the provider's implementation without a really good reason I'd shut them down.

> Also, an maybe this is just a cynical view, but when you start your cautionary tale with a literal, "It all started when I was 11", it's kind of hard to relate.

I can relate to that, so guess that one's on you. ;)

What is NIH?

Not Invented Here, a term normally used to describe the thinking that instead of using libraries we should write all our own code.

I'm thinking "Not Invented Here".

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact