5 ms·

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

by inoda 8y ago

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.

rblatz 8y ago
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.
- inoda 8y ago
  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.
  - rblatz 8y ago
    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.
    - f0rgot 8y ago
      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.
      - cagmz 8y ago
        This is exactly how our integration works, as well.
treis 8y ago
>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?
- inoda 8y ago
  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.
  - treis 8y ago
    >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.
    - inoda 8y ago
      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.
      - Bamafan 8y ago
        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).
        deleted 8y ago
        [deleted]
        8y ago
Bamafan 8y ago
When I read retrospectives like this, I wonder how many apps have this bug and don't know it.
sunir 8y ago
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).
- lowercased 8y ago
  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.
  - deleted 8y ago
    [deleted]
aboutruby 8y ago
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).
inoda 8y ago
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.
- justinclift 8y ago
  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. :(
- charlie0 8y ago
  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.
matchagaucho 8y ago
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)
- inoda 8y ago
  Users (our app users) would have created their own templates and used them for sending envelopes.

by inoda 8y ago

rblatz 8y ago

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.

inoda 8y ago
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.
- rblatz 8y ago
  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.
  - f0rgot 8y ago
    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.
    - cagmz 8y ago
      This is exactly how our integration works, as well.

treis 8y ago

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

inoda 8y ago
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.
- treis 8y ago
  >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.
  - inoda 8y ago
    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.
    - Bamafan 8y ago
      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).
      - deleted 8y ago
        [deleted]
      - 8y ago

Bamafan 8y ago

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

sunir 8y ago

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

lowercased 8y ago
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.
- deleted 8y ago
  [deleted]

aboutruby 8y ago

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

inoda 8y ago

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.

justinclift 8y ago
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. :(
charlie0 8y ago
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.

matchagaucho 8y ago

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)

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