Hacker News Reader

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?

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.

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.

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