0

We had a working application, we went through the go-live process, and everything was running live for several days. Then we started getting SSL errors, and we saw that the nuget package for the DocuSign package had an update (I believe this was all for the 11/13/2019 2019 certificates auto-update), so we updated our code, but now every request returns the USER_LACKS_MEMBERSHIP error for every token-authenticated request.

Things I can confirm are not the issue:

  • We have authenticated the app via account.docusign.com and the oauth signature impersonation scope, and the testing and live paths are in the API approved Redirect URIs.
  • We have the correct base path in the configuration (https://na3.docusign.net, as shown on our Apps and Keys page)
  • The base path did not change after we get the token back (The BaseUri on the Account object matches what we started with)
  • We are using the correct user for the configuration (The value labeled "API Username" in the Apps and Keys page is entered as "IMPERSONATED_USER_GUID" in appsettings.json and successfully used in creating the token as parameter UserID, which also matches our user account's ID shown in the backend, so we are not confusing it with TARGET_ACCOUNT_ID or CLIENT_ID, and shuffling those around causes errors much earlier at the token generation step).

We only have one user: the administrator of the DocuSign account. Their ID appears in the API configuration labeled as "API Username". The DocuSign administration backend doesn't display a membership tab anywhere for us to correct any possible issues with a user lacking membership. As far as I can tell, Membership is a higher tier account option than what we're paying for, so I'm confused how we could be having problems with a feature we haven't bought.

We get this error for checking envelope status. We get this error for trying to create new envelopes. We get this error for trying to get Account information. The only thing we can do is get an authentication token, but then that token can't be used to make any further authenticated requests.

Is there anything I'm missing that could be causing this other than some database error on DocuSign that I can't correct through the tools available to me? The package update changed the order of which class constructor accepts the ApiClient object, and there's a new AccessToken field on the Configuration class (which I filled out, but doesn't seem to have any effect, since we're still adding the Authorization/Bearer header manually). I'm out of ideas on what to try next.

  • 1
    Have you checked out https://stackoverflow.com/questions/29807801/docusign-user-lacks-membership-issue – Xavier Dec 02 '20 at 19:32
  • Yes, and that's why I included the 4th bullet point. We are absolutely using the correct user, he is active, and I have verified the user ID in four different locations which I listed. Any other ideas? – TravellingStickSalesman Dec 02 '20 at 20:14
  • when you make your API calls, you also pass an accountId, that should match as well. So you have userId and AccountID and they must be both from the same account – Inbar Gazit Dec 02 '20 at 20:59
  • I am definitely sending the correct ID on the individual request as well. The parameter you're talking about on envelopesApi.CreateEnvelope is labeled accountID, and I am using TARGET_ACCOUNT_ID there. Any other ID from the set of identically-structured GUIDs provided results in the PARTNER_AUTHENTICATION_FAILED error. Only sending TARGET_ACCOUNT_ID (as I was doing when this worked originally, mind you) results in the USER_LACKS_MEMBERSHIP error. If the error was where you are suggesting, I would not be getting USER_LACKS_MEMBERSHIP as the error. – TravellingStickSalesman Dec 02 '20 at 21:34

1 Answers1

0

Are you using the production environment or the demo environment? I suspect that what's happening is that you are getting them mixed. As the baseUrl should not be demo.docusign.net etc. if you're using production (as indicated by your na3.docusign.net address) but you must ensure that the same account/user from production is also used. So, the 4 things to check:

  1. userId
  2. accountId.
  3. baseURI
  4. authURI (account-d.docusign.com vs. account.docusign.com)

All of these should match and be for the same account in the same env.

Inbar Gazit
  • 12,566
  • 1
  • 16
  • 23
  • Yes, see bullet points #1, #2 and #4. These are not getting mixed up. They are correct. They are all the live values. I have checked these multiple times which is why I said that I had checked these when I made the post. – TravellingStickSalesman Dec 02 '20 at 21:13
  • are you using the C# SDK? can you reproduce this with postman? – Inbar Gazit Dec 02 '20 at 21:38
  • I am using the C# SDK, which is why I mentioned the nuget package in my post. I haven't used postman before, but it's failing due to CORS. Not sure how it would help, since it's presumably going to be doing the same thing that the SDK is doing. Does postman have any easy setup option for DocuSign? Or do I have to set up the entire oauth token request and usage by hand? I was hoping I wouldn't have to end up debugging the SDK itself. – TravellingStickSalesman Dec 02 '20 at 22:04
  • I would like to know the URL that you are calling into? that's why I mentioned postman – Inbar Gazit Dec 02 '20 at 22:53
  • I was just testing the endpoint without the full oauth authentication to see if I would get the unauthorized response, but CORS prevents postman (browser version) from reaching it. https://na3.docusign.net/restapi/accounts/[ACCOUNT ID REMOVED] What I should get is PARTNER_AUTHENTICATION_FAILED, same as if I had entered the URL in a browser. – TravellingStickSalesman Dec 03 '20 at 16:11
  • you can download the postman tool and run it from your computer. – Inbar Gazit Dec 03 '20 at 16:40