能否无需模板在应用中嵌入DocuSign签署并支持双签署方式？

Absolutely! You don’t need a DocuSign template to set up embedded signing alongside email signing—this works seamlessly with your existing template-free envelope creation workflow, and you can even support both signing methods for different recipients (or let users choose, depending on your use case) in the same envelope.

Here’s how to adjust your current process to add embedded signing:

Key Step: Mark Recipients for Embedded Signing #

When defining your envelope’s recipients, add a clientUserId property to any signer who should use embedded signing. This unique identifier (usually a user ID from your own system) tells DocuSign that this signer will access the envelope through your app, not via email.

For example, in your envelope creation request, your recipients might look like this:

"recipients": {
  "signers": [
    {
      "email": "john.doe@example.com",
      "name": "John Doe",
      "recipientId": "1",
      "clientUserId": "your_app_user_123", // Enables embedded signing for this user
      "tabs": {
        "signHereTabs": [
          {
            "documentId": "1",
            "pageNumber": "1",
            "xPosition": "150",
            "yPosition": "250"
          }
        ]
      }
    },
    {
      "email": "jane.smith@example.com",
      "name": "Jane Smith",
      "recipientId": "2"
      // No clientUserId = this signer gets an email invitation to sign
    }
  ]
}

Notice that you can mix signers with and without clientUserId to support both signing methods in one envelope.

Generate the Embedded Signing URL #

Once you’ve created the envelope successfully, call the createRecipientView API endpoint to generate a temporary, secure URL that you can embed in your app. This request needs to match the clientUserId, email, and name of the embedded signer, plus a returnUrl where the user will be redirected after signing (or if they cancel).

A sample request body for this endpoint looks like:

{
  "returnUrl": "https://your-app.com/signing-complete",
  "authenticationMethod": "none", // Use your preferred auth method (e.g., "email" for verification)
  "email": "john.doe@example.com",
  "userName": "John Doe",
  "clientUserId": "your_app_user_123"
}

The response will include a url field—this is the embedded signing page you can load in an iframe or new tab within your application.

Important Notes #

• Consistent clientUserId: Make sure the clientUserId you use in the createRecipientView request matches exactly what you set when creating the envelope. Mismatches will cause errors.
• Signing Tabs: Just like with your current workflow, you’ll need to define all signing tabs (Sign Here, Initial Here, etc.) directly in the envelope creation request—no template required.
• Flexibility: You can dynamically decide per signer whether to use embedded or email signing based on your app’s logic (e.g., let users choose their preferred method when initiating the envelope).

This approach fits perfectly with your existing template-free setup, so you won’t need to overhaul your current code—just add the clientUserId property and the recipient view API call for embedded signers.

内容的提问来源于stack exchange，提问作者Barry Chapman