Docusign Bulk Send Shared Access API: What Changed

01 Oct 2026

9 min

Docusign IAM

Automation

Implementation

Docusign's eSignature 26.3.00.00 release, live on the Demo environment since September 2026, extends Shared Access to cover Bulk Send and batch-level actions, closing a gap integrators have hit since the feature launched. If your CRM, ERP, or custom app triggers Bulk Send on behalf of a team, this is the release to test before it reaches production.

What actually changed in the September 2026 release

Docusign's own release hub describes the update as "Shared Access to Support Bulk Send and Batch Actions." Before this release, Shared Access let one user view, edit, or manage another user's envelope inbox, but it explicitly excluded Bulk Send: Docusign's support documentation on Shared Access to Envelopes states that "for the initial launch of the shared access feature, you cannot send a bulk send envelope on behalf of another user." Customers confirmed the same limitation on the Docusign Community: you could see another user's bulk send envelopes through Shared Access, but you could not send new ones on their behalf.

What is Docusign Shared Access, in plain terms?

Shared Access is a Docusign eSignature permission that lets one user (the delegate) send, edit, or manage envelopes in another user's (the principal's) account, without logging in as that person or sharing credentials. An admin configures the relationship in Docusign Admin, or a user grants it directly under My Preferences > Shared Access, per Docusign's documentation. It's the feature behind "send this agreement while I'm out" and "let my assistant manage my envelope inbox." Until this release, it stopped at the edge of Bulk Send.

	Before 26.3.00.00	After 26.3.00.00 (Demo, Sept 2026)
View/manage another user's envelopes	Supported	Supported
Send a single envelope on behalf of another user	Supported	Supported
Send a Bulk Send batch on behalf of another user	Not supported	Supported
Batch-level correct/resend/void/rename on behalf of another user	Not supported	Supported

The 26.3.00.00 release removes that restriction. Once it reaches production, a user with delegated Shared Access permissions will be able to:

Send a Bulk Send batch on behalf of another user
Correct, resend, void, or rename envelopes at the batch level on behalf of another user

The same release also ships a new "Report Abuse" button on WhatsApp messages sent through Docusign, part of a broader trust and safety push alongside the Shared Access change. It is a separate feature from the Bulk Send update and does not touch the API surface integrators care about, so we won't dwell on it here beyond noting it is real and shipped in the same version.

Why this matters for integrations, not just admins

Most Docusign customers read Shared Access as an internal delegation feature: an assistant sends on behalf of an executive, a backup covers for someone on leave. That framing undersells what changes for teams that trigger Bulk Send programmatically from a CRM, ERP, or custom portal.

Here's the pattern that breaks today. Say a sales operations team builds an integration that fires a Bulk Send batch from Salesforce every time a cohort of deals closes, using one service account's credentials. Before this release, that service account had to be the literal owner of the bulk send permission, because Shared Access couldn't extend to bulk sends. Any attempt to centralize sending under a shared service identity while preserving "who actually initiated this batch" as a separate, delegated concept ran into the same wall the community thread above describes.

With Shared Access now covering Bulk Send, an integration can authenticate as a delegate and send on behalf of the envelope owner using the X-DocuSign-Act-On-Behalf header, which Docusign's developer docs describe as the mechanism for making API calls on behalf of a principal once access has been shared. That is a meaningfully different integration shape than impersonating a single shared account: the envelope's sender of record becomes the principal user, not the delegate, which is the detail that matters for audit trails and envelope ownership reporting once multiple people can trigger sends against the same account.

If your integration logs "who sent this envelope" by capturing the authenticated API user rather than resolving the on-behalf-of principal, test that assumption against the Demo environment now. Reports and audit exports built against the old single-owner Bulk Send model may need a mapping step once Shared Access-driven bulk sends start appearing with a different sender identity than the API caller.

How to test it before it hits production

Docusign's release cadence gives you a real window here. Per Docusign's own Release Notes FAQ, Demo releases ship roughly two weeks ahead of Production, and Production rollouts begin the first Friday of each month and take about four days to reach all regional sites. The October 2026 release notes (26.3.01.00) are already live on Demo too, which is the normal pattern: features announced one month typically become the production default within a release cycle or two.

A practical test plan for the next two to four weeks:

Set up Shared Access between a test "owner" account and a test "delegate" account in your Demo tenant.
Trigger a Bulk Send batch from the delegate, on behalf of the owner, using the X-DocuSign-Act-On-Behalf header.
Check what your integration's envelope status webhook or polling job records as the sender for that batch, and compare it against what your audit log or CRM activity feed shows.
Run a batch-level correct, resend, and void on behalf of the owner and confirm your integration's event handling doesn't assume only the original sender can issue those actions.
If you consume Docusign Connect webhooks for envelope events, verify the payload fields you parse for sender identity still resolve correctly when Shared Access is involved.

A minimal example of the header in an API call, once Shared Access has been granted and you're authenticated as the delegate:

text

POST /restapi/v2.1/accounts/{accountId}/envelopes
Authorization: Bearer {delegate_access_token}
X-DocuSign-Act-On-Behalf: {principal_user_id}
Content-Type: application/json

{
  "emailSubject": "Please sign this agreement",
  "status": "sent",
  ...
}

The delegate authenticates normally, then the X-DocuSign-Act-On-Behalf header tells the eSignature API which principal's permissions and envelope ownership the call should resolve against, per Docusign's Shared Access how-to guide.

If step 3 or 5 surfaces a mismatch, that's your fix-it list before this ships to production, not after.

If you relay Docusign Connect webhook events into a CRM or ERP through a middleware layer, this is also a good moment to confirm that layer handles retries and signature verification correctly when the sender identity on an event changes. Baton is built specifically for that job: relaying Docusign webhook events to Workflow Builder and other systems with HMAC verification and retry logic, so a mismatched sender field doesn't silently drop downstream automation.

Where this fits in the broader Shared Access picture

This release is part of a pattern we've tracked since Shared Access first launched: Docusign ships delegation and collaboration features for human workflows first, then extends them to cover the automated, API-driven paths that integrations depend on. The same thing happened with envelope-triggering patterns from source platforms, where early workflow automation support lagged behind what teams actually needed to wire CRMs and ERPs into Docusign reliably.

If you're mid-build on a Docusign integration and haven't mapped out how Shared Access, Bulk Send, and your authentication model interact, this is a good checkpoint to do it. Our Docusign IAM implementation guide covers the broader authentication and permissions decisions that integrations like this depend on, including where Shared Access fits relative to impersonation and JWT grants.

Frequently asked questions

Does Shared Access now let me send Bulk Send envelopes on behalf of another user? Yes, as of the Docusign eSignature 26.3.00.00 release (Demo, September 2026). Before this release, Docusign's own documentation explicitly excluded Bulk Send from Shared Access; the September release adds support for sending Bulk Send batches, plus batch-level correct, resend, void, and rename actions, on behalf of another user.

What header do I use to send on behalf of another user via the API? Docusign's developer documentation on Shared Access specifies the X-DocuSign-Act-On-Behalf header, substituted with the principal user's identifier, for API calls made on behalf of a user who has shared access.

When will this reach the production environment? Docusign publishes Demo release notes roughly two weeks ahead of Production, according to its Release Notes FAQ, with Production rollouts starting the first Friday of each month. Docusign's October 2026 Demo release notes (26.3.01.00) are already published, which fits the usual one-to-two release cycle turnaround from Demo to Production.

Does this change who shows up as the sender of record on an envelope? This is the detail integrators should test directly rather than assume. Once Shared Access covers Bulk Send, a delegate can trigger a batch using the on-behalf-of header, and the envelope's sender of record is expected to resolve to the principal account, not the delegate's credentials. Confirm this against your own Demo environment and audit log before relying on it for compliance reporting (unverified at the granular field level pending direct testing).

Is the WhatsApp abuse reporting change related to Bulk Send or Shared Access? No. The new "Report Abuse" button on WhatsApp messages, also part of the 26.3.00.00 release per Docusign's release hub, is a separate trust and safety feature for message delivery channels. It doesn't touch the Bulk Send or Shared Access API surface.

What to do next

If you run a Bulk Send integration today, especially one built for a sales, legal ops, or procurement team where more than one person needs to trigger sends under shared permissions, treat this release as your test window, not a surprise for later. Stand up the scenario in Demo, confirm your sender-of-record logic and webhook parsing hold up, and fix what breaks now while you have a release cycle of runway.

If you're earlier in the process and still deciding how Shared Access, impersonation, and service accounts should fit together for a new Docusign integration, talk to the fluidlabs team about a Docusign IAM working session. We build these integration patterns for a living, and getting the authentication model right before you scale a Bulk Send workflow across a team is a lot cheaper than untangling it after the fact.