Skip to main content
arrow-left Back to Docusign.com
Newcomer
paramrana78Newcomer
Newcomer
September 18, 2026
Question

Android Mobile SDK 2.1.7: launchCaptiveSigning() throws "DSAuthUser data is null" even with valid Integration Key (URL-based captive signing)

Using the Android Mobile SDK (com.docusign:androidsdk:2.1.7) to launch
captive/embedded signing from a pre-generated signing URL (obtained
server-side via the eSignature REST API's EnvelopeViews: createRecipient),
not via SDK-driven OAuth login — our app's signers don't have their own
DocuSign accounts.

Setup:
  DocuSign.init(context, integratorKey, DSMode.DEBUG)
  // integratorKey is a real, valid Integration Key from Apps and Keys

Call:
  DocuSign.getInstance().getSigningDelegate()
    .launchCaptiveSigning(activity, signingUrl, envelopeId, listener)

DocuSign.init() succeeds with no error. But launchCaptiveSigning() always
fails before the signing UI ever appears, with:

  com.docusign.androidsdk.exceptions.DSAuthenticationException:
  DSAuthUser data is null

Full stack trace shows the failure originates inside the SDK's own
envelope fetch:

  E DocuSign_Auth: DSAuthUser is null
  E DocuSign_EnvelopeRepository: Error while fetching the envelope
    com.docusign.androidsdk.exceptions.DSAuthenticationException:
    DSAuthUser data is null
    at com.docusign.androidsdk.domain.db.repository.EnvelopeRepository
      .fetchEnvelopeSingle$lambda$78(EnvelopeRepository.kt:2003)

This reproduces 100% of the time, on every fresh session, with a real
envelope and a real Integration Key.

On iOS, the equivalent SDK call —
DSMEnvelopesManager.presentCaptiveSigningWithPresentingController:
signingUrl:envelopeId:recipientId:animated:completion: — works exactly as
documented: no SDK login/auth needed at all, and the signing ceremony
completes successfully end-to-end using only the signing URL.

Looking at the Android SDK's DSAuthenticationDelegate, there IS a
loginWithAccessToken method that would match iOS's no-login pattern, but
it's declared private — not callable from app code. Every public login()
overload requires a Context + DSAuthenticationListener and appears to
drive DocuSign's own interactive OAuth/login UI, which isn't usable for
our use case (headless, signer has no DocuSign account).

Questions:
1. Is an authenticated SDK session genuinely required for
   launchCaptiveSigning() on Android, unlike iOS's URL-based method?
2. If so, is there a supported way to authenticate silently with a
   pre-obtained token/session (matching iOS's loginWithAccessToken),
   or is the interactive login() flow the only option?
3. Is this a known gap versus the iOS SDK, and is there a newer SDK
   version or an undocumented setup step that resolves it?
 

3 replies

Docusign Employee
adrian.castroDocusign Employee
Docusign Employee
September 19, 2026
Hello Paramrana78,
 
Thank you for contacting Docusign Community Support. 

We appreciate the detailed description.  

As you mentioned, it may be a difference between our iOS and Android SDK, we will check with our internal team.
 
Best regards,
 
Adrian | Docusign Customer Support
Translate
Docusign Employee
adrian.castroDocusign Employee
Docusign Employee
September 23, 2026

 

Hello Paramrana78,

Our SDK team mentioned:

Authenticated SDK session is not required if a signing URL is generated already.
It looks like they are invoking a different launchCaptiveSigning  API.
GitHub API

They recommended to use this API to launch your signing session:
fun launchCaptiveSigning(context: Context, signingURL: String, envelopeId: String?, recipientId: String?, listener: DSCaptiveSigningListener)

envelopeId and recipientId can be passed as null which then would look like this.
 fun launchCaptiveSigning(context, signingURL, null, null, listener) 

 

We hope this helps 

 

Regards

Adrian

DevSupport at Docusign

Translate
Newcomer
paramrana78NewcomerAuthor
Newcomer
September 23, 2026

Hi Adrian,

Thank you! please pass our thanks to the SDK team. That was exactly it, and captive signing now works on Android.

The root cause turned out to be the overload signature rather than authentication. We were calling launchCaptiveSigning(context, envelopeId, recipientClientUserId, listener)

and passing our pre-generated signing URL as the second argument, so the SDK treated the URL as an envelope id and took the envelope-fetch path, which does require an authenticated session, hence
DSAuthUser data is null every time.
Switching to launchCaptiveSigning(context, signingURL, envelopeId, recipientId, listener) resolved it immediately, with no SDK login. Tested on androidsdk:2.1.7, passing our real envelopeId and recipientId rather than nulls.

Worth flagging for the SDK team: since the two overloads differ only in arity and the second parameter changes meaning between them, this is easy to hit, and the resulting error points at authentication rather than the actual cause. A clearer error when the value in the envelopeId position isn't a valid envelope id would help.

One follow-up: if the user dismisses CaptiveSigningActivity with the system Back button, none of the DSCaptiveSigningListener callbacks fire: no onCancel, no onError , so the app gets no signal the ceremony ended. Is that intended, or should Back be reported as a cancellation?

Thanks again for the quick turnaround.

 

Translate
Code of ConductAccessibility statement

Docusign Community

Code of Conduct