DocuSign SDKs & Libraries: Official and Community Integrations (2026)

SDKs overview

DocuSign provides Software Development Kits (SDKs) to facilitate the integration of its e-signature and agreement workflow functionalities into custom applications. These SDKs are designed to abstract the complexities of direct REST API calls, offering language-specific clients that manage authentication (primarily OAuth 2.0 protocol), request construction, and response parsing. By using an SDK, developers can interact with the DocuSign eSignature API using familiar programming paradigms, reducing the amount of boilerplate code required and accelerating development cycles.

The core DocuSign eSignature REST API serves as the foundation for these SDKs, enabling operations such as sending documents for signature, retrieving signed documents, managing envelopes, and administering user accounts programmatically. The official SDKs are maintained by DocuSign and are available for several popular programming languages, ensuring broad compatibility and support for various development environments. These SDKs are typically open-source and hosted on platforms like GitHub, allowing community contributions and transparency in their development.

Beyond the official offerings, a vibrant community of developers also contributes a range of third-party libraries and tools. While not officially supported by DocuSign, these community-driven projects can offer specialized functionalities, alternative language support, or integrations with specific frameworks. Developers should evaluate community libraries based on their maintenance, documentation, and licensing before incorporating them into production systems.

Official SDKs by language

DocuSign maintains official SDKs for several programming languages, providing a streamlined experience for developers to integrate e-signature capabilities. These SDKs are designed to align with the latest versions of the DocuSign eSignature REST API, ensuring access to current features and security protocols. Each SDK typically includes client libraries, example code, and comprehensive documentation to assist with implementation.

The table below lists the primary official SDKs, their common package managers, and installation commands. Developers can find detailed documentation and release notes for each SDK on the DocuSign Developers site.

Installation

Installation of DocuSign SDKs typically follows standard practices for each programming ecosystem. The process generally involves using a language-specific package manager to add the SDK as a dependency to your project. Before installation, ensure you have the correct version of your language runtime and package manager installed.

C#

For C# projects, the DocuSign eSign .NET SDK is distributed via NuGet. You can install it using the .NET CLI or the Package Manager Console in Visual Studio.

dotnet add package DocuSign.eSign.dll

Install-Package DocuSign.eSign.dll

Java

Java developers typically use Maven or Gradle to manage dependencies. Add the following to your pom.xml (Maven) or build.gradle (Gradle) file.

<!-- Maven -->
<dependency>
    <groupId>com.docusign</groupId>
    <artifactId>docusign-esign-java</artifactId>
    <version>5.13.0</version> <!-- Check for the latest version -->
</dependency>

// Gradle
implementation 'com.docusign:docusign-esign-java:5.13.0' // Check for the latest version

Node.js

The Node.js SDK is available on npm. Install it using the npm or yarn package manager.

npm install docusign-esign
# or
yarn add docusign-esign

PHP

PHP projects use Composer for dependency management. Add the DocuSign eSign client to your project's composer.json and run composer install.

composer require docusign/esign-client

Python

The Python SDK can be installed using pip.

pip install docusign-esign

Ruby

Ruby developers can install the SDK using RubyGems.

gem install docusign_esign

Quickstart example

This Python example demonstrates how to create an envelope, add a document, define a recipient, and send it for signature using the DocuSign eSignature SDK. This quickstart assumes you have already obtained an access token via OAuth 2.0 and possess the necessary account ID and base URL. For full authentication flow details, refer to the DocuSign authentication guide.

import base64
from docusign_esign import ApiClient, EnvelopesApi, EnvelopeDefinition, Document, Signer, RecipientViewRequest, Tabs, Text, SignHere

# Configuration (replace with your actual values)
ACCESS_TOKEN = "YOUR_ACCESS_TOKEN"
ACCOUNT_ID = "YOUR_ACCOUNT_ID"
BASE_PATH = "https://demo.docusign.net/restapi" # Use demo for testing
SENDER_EMAIL = "[email protected]"
SENDER_NAME = "Sender Name"
RECIPIENT_EMAIL = "[email protected]"
RECIPIENT_NAME = "Recipient Name"

# Path to the document to be signed
DOCUMENT_PATH = "path/to/your/document.pdf"

def send_document_for_signature():
    try:
        # Initialize the API client
        api_client = ApiClient()
        api_client.host = BASE_PATH
        api_client.set_default_header("Authorization", f"Bearer {ACCESS_TOKEN}")

        envelopes_api = EnvelopesApi(api_client)

        # Read and base64 encode the document
        with open(DOCUMENT_PATH, "rb") as file:
            content_bytes = file.read()
        base64_document = base64.b64encode(content_bytes).decode("utf-8")

        # Create the document model
        document = Document(
            document_base64=base64_document,
            name="Example Document",
            file_extension="pdf",
            document_id="1"
        )

        # Create a signer recipient
        signer = Signer(
            email=RECIPIENT_EMAIL,
            name=RECIPIENT_NAME,
            recipient_id="1",
            routing_order="1"
        )

        # Create a SignHere tab (signature field)
        sign_here_tab = SignHere(
            document_id="1",
            page_number="1",
            x_position="100",
            y_position="100"
        )
        
        # Create a text tab (custom text field)
        text_tab = Text(
            document_id="1",
            page_number="1",
            x_position="300",
            y_position="150",
            font="Arial",
            font_size="size12",
            value="This is a custom text field.",
            tab_label="CustomText"
        )

        # Add tabs to the signer
        signer.tabs = Tabs(sign_here_tabs=[sign_here_tab], text_tabs=[text_tab])

        # Define the envelope
        envelope_definition = EnvelopeDefinition(
            email_subject="Please sign this document",
            documents=[document],
            recipients=docusign_esign.Recipients(signers=[signer]),
            status="sent" # Set to 'sent' to send the envelope immediately
        )

        # Create and send the envelope
        new_envelope = envelopes_api.create_envelope(account_id=ACCOUNT_ID, envelope_definition=envelope_definition)
        print(f"Envelope sent successfully! Envelope ID: {new_envelope.envelope_id}")

        # Generate a recipient view URL for embedded signing (optional, for web apps)
        recipient_view_request = RecipientViewRequest(
            authentication_method="None",
            client_user_id="1", # Must match recipient_id
            return_url="https://www.docusign.com/devcenter", # URL to return to after signing
            user_name=RECIPIENT_NAME,
            email=RECIPIENT_EMAIL
        )
        recipient_view = envelopes_api.create_recipient_view(ACCOUNT_ID, new_envelope.envelope_id, recipient_view_request=recipient_view_request)
        print(f"Recipient View URL: {recipient_view.url}")

    except Exception as e:
        print(f"Error sending envelope: {e}")

if __name__ == "__main__":
    send_document_for_signature()

This example sets up an API client, constructs an envelope with a PDF document, defines a signer, and places a signature field and a custom text field on the document. Finally, it sends the envelope for signing. The optional recipient view URL generation demonstrates how to enable embedded signing experiences, common in web applications. Developers should replace placeholder values with their actual credentials and document paths.

Community libraries

While DocuSign provides official SDKs for major programming languages, the broader developer community also contributes a variety of libraries and tools that can extend or complement DocuSign integrations. These community-driven projects can offer solutions for niche programming languages, specific framework integrations, or specialized use cases not covered by the official SDKs.

Examples of community contributions might include:

• Unofficial SDKs for less common languages: Developers might create clients for languages like Go, Rust, or Swift, enabling broader platform support.
• Framework-specific wrappers: Libraries designed to integrate seamlessly with popular web frameworks (e.g., Django, Ruby on Rails, Laravel) or mobile development platforms.
• Utility libraries: Tools that simplify common tasks like document generation, advanced template manipulation, or specific webhook handling.
• Integrations with other services: Connectors that bridge DocuSign with other platforms, such as enterprise resource planning (ERP) systems or customer relationship management (CRM) software, beyond official marketplace apps.

When considering a community library, it is important to assess its reliability and ongoing maintenance. Key considerations include:

• Active development: Is the library regularly updated to support new API features and security patches?
• Documentation quality: Is the documentation clear, comprehensive, and easy to follow?
• Community support: Is there an active community (e.g., GitHub issues, forums) for troubleshooting and assistance?
• Licensing: Does the license (e.g., MIT, Apache 2.0) align with your project's requirements?
• Security practices: Has the library undergone any security audits or does it follow best practices for handling sensitive data and authentication?

Platforms like GitHub are primary repositories for discovering these community projects. Searching for "DocuSign" alongside a specific language or framework can reveal relevant repositories. While community libraries can offer flexibility, official SDKs are generally recommended for mission-critical applications due to direct vendor support and guaranteed compatibility with the latest API versions. For enterprise-grade integrations requiring high levels of security and compliance, a thorough review of any third-party component is essential, as highlighted in general application security best practices.