Saved signature doesn't load when signing via API signingUrls (loads fine via email link)

​Hi @Sughosh ,

Hope you're doing well and thanks for such a detailed and well-documented report. Let me walk through what is likely happening and what your options are, but first, a few questions to help us narrow things down further.

A few things I would like to understand before going deeper:

1. When the signing page opens via the signingUrls flow, does the signer see the signature panel at all, or is the saved signature simply missing from it? That is, does the panel show up blank, or does it not load at all?

2. What authentication method is configured on this agreement? You mentioned ADOBE_SIGN authentication. Is the signer being challenged to re-authenticate at the point of signing through the embedded portal, or is the URL presented directly without an Adobe login challenge?

3. Is the signer account an internal Acrobat Sign account user on the same Sign account as the sender, or is it a different Adobe account (for example, a personal Adobe ID)?

4. When you test with the email link, does the signer explicitly log in to their Adobe account before seeing the saved signature? Or does it appear even without a fresh Sign login?

What is most likely happening here

In an embedded signing workflow, the signing URL from GET /agreements/{agreementId}/signingUrls is a direct link to the signing session. It is not tied to an Adobe login. Acrobat Sign does not independently verify that the person opening the URL is the intended signer. The integration model assumes your application has already established who the user is. For more information please check the help page https://adobe.ly/4wwTSlS

This is the key difference between the two flows:

When a signer uses the email link, they click through from their inbox, and Acrobat Sign evaluates whether they already have an active, authenticated Adobe Sign session. When a user accesses a signing link while already authenticated in Acrobat Sign, the service evaluates the userID attempting access and compares it to the userID assigned to the link. If the authenticated userID matches the signing userID, access is granted. That matched authenticated session is what allows Acrobat Sign to look up and pre-load the signer's Personal Preferences signature.

When a signer uses the API signingUrls link, Acrobat Sign receives no identity context. The session arriving at the signing page is not associated with an Adobe Sign userID, even if the same person is logged in to Adobe in another browser tab. The saved signature lookup depends on that identity context being present in the signing session itself, and with signingUrls, it simply is not there unless the signer is actively authenticated through the Sign authentication challenge within the flow.

This is not a vulnerability in Acrobat Sign. It is a consequence of the integration model https://adobe.ly/4wwTSlS

Step-by-step things to try

Step 1: Verify the authentication challenge is completing inside your portal

Even if you have ADOBE_SIGN authentication set on the agreement, the question is whether the challenge is being surfaced and completed inside your embedded portal or being bypassed. If the challenge is completing and the signer is authenticating to their Adobe Sign account inside the embedded session, the saved signature should load. Check your agreement's audit trail to confirm a Sign authentication event is recorded.

You can review the official article on Acrobat Sign Authentication here: https://adobe.ly/4bmkuO8

Step 2: Check the "Allow recipients to use their saved signature" account setting

You mentioned you have set this to "All recipients," which is correct. However, confirm that the group the agreement is being sent from also inherits this setting rather than overriding it at the group level. Navigate to Account Settings > Signature Preferences to verify. You can see how saved signature preferences work here: https://adobe.ly/4xeU893

Step 3: Check the Signer Identity Verification setting on the account

The Signer Identity Verification feature requires that any user in your Acrobat Sign account must authenticate to Acrobat Sign before applying their signature. When an agreement is sent to a signer in the account from a trusted source, the user is challenged to authenticate to Acrobat Sign immediately after selecting the Review and sign link in the email. This login challenge is what creates the identity-bound session that loads the saved signature. Check whether this feature is enabled and whether it applies to your embedded flow as well.

This setting is found at: Account Settings > Security Settings > Signer Identity Verification. Documentation is here: https://adobe.ly/4wBaU29

Step 4: Review your embedded signing identity and authentication design

Adobe now has a dedicated help article specifically covering how signer identity and Personal Preferences work in the signingUrls API pattern. This is worth reading end to end as it directly addresses your scenario: https://adobe.ly/4wwTSlS

Step 5: Review the Acrobat Sign API REST v6 documentation for signingUrls

The official REST v6 API reference documents the endpoint behavior and any identity-related parameters: https://adobe.ly/452UOm8

What this likely means for your integration design

For agreements where the stakes are higher, consider configuring Acrobat Sign's Email OTP or Acrobat Sign Authentication on the agreement. This shifts identity verification into the signing flow itself and records it directly in the audit trail, giving you a stronger evidentiary record without relying solely on your application's logs https://adobe.ly/4wwTSlS

In practice: if the signer completes an ADOBE_SIGN or Email OTP authentication challenge inside your portal's embedded session, Acrobat Sign should have the identity context needed to look up Personal Preferences. The key is that the challenge must be completed within the same embedded session, not in a separate browser tab or outside the portal. This is the most likely root cause of the behavior you are seeing.

Please share your answers to the questions above and let us know what you find in the audit trail and Signer Identity Verification settings. That will help us determine whether this needs to be escalated to the engineering team or can be resolved through configuration.

~Amal