Skip to navigation
Planning a partner implementation

Partner implementation overview

View as Markdown

What type of partner are you?

An Independent Software Vendor (ISV) builds software products to license to other businesses. ISV products include business applications such as HCM, CRM, and ERP applications. An ISV Partner is an ISV that partners with Docusign to add access to Docusign functionality and services to their applications. There are multiple ISV programs available to ISVs that participate in the Docusign Partner Program.

Discover your options for partnering with Docusign and get recommended steps for building your eSignature integration based on your choice of partnership model.

Feel free to share these details with others in your team or company to determine which option may best suit your needs. If this does not meet your needs or if you need further help, please file a ticket for help with Partner support.

Are you building an eSignature integration as an ISV?

The following sections provide a high-level outline of the steps and considerations you should consider as an ISV partner with Docusign.

Design

Create a plan for the design of your integration before you start building. This section provides an overview of some basic design questions, prompts, and guidelines to help you get started with asking the questions you should answer before you build your integration. For a more exhaustive in-depth analysis of each design consideration, see ISV general connector implementation plan or ISV Embed (OEM) implementation plan.

Define your use case and customer journey by identifying your product’s use case and how you will integrate with Docusign. Will you be integrating your product with each customer’s Docusign account (ISV Referral) or will you embed Docusign eSignature as part of your product offering (ISV Embed)?

The following diagram outlines the important design decision points for each stage in your customer journey.

Diagram showing highlighted steps of the design process for ISV partners

  1. Authentication and Authorization: Which OAuth method is the best for you? Docusign provides multiple OAuth methods to choose from, designed to accommodate different integration requirements.

  2. Envelope design:

    • User experience: Determine which envelope design experience fits your application best.

      • You can use the API to directly build the entire Docusign envelope in your application before sending it.
      • You can pass the user experience over to the Docusign sender view (embedded sending) to enable the sender to finish actions (such as interacting with tabs, take workflow actions, or meet recipient auth requirements) and send the envelope.
      • You can also provide both API direct path and embedded sender view This option provides the most flexibility and is ideal.

    • Documents: Your integration can send multiple documents in a single envelope.

      • Direct document contribution (generated or uploaded by your app)
      • Reusable Docusign templates
      • Both direct contribution and through templates

    • Recipients: Envelopes can involve multiple recipients and recipient types to support a wide range of workflow models and use cases.

    • Tabs/Fields: Your integration can write data to documents using tabs (also called fields). The values of these tabs can be pre-populated by your application and/or filled in by the recipients.

      • There are several ways to place tabs in your documents. Review and consider which methods will work best for your application.
      • Consider supporting the ability to merge data into the tab fields as well as the email subject and body.

    • Localization: Docusign provides multiple language support for signers. If you plan on using localization, consider the need to specify specific email subjects and localized notes.

      Recommendation: Use composite templates whenever possible for creating your envelopes. Composite templates are easier to expand and adapt to your workflows, and they support workflows that template references don’t. See Why You Should Be Using the Composite Template Model for details.

  3. Envelope signing: Docusign offers multiple delivery options for signing sessions. Envelopes can be sent for signature via email, SMS text or hosted (embedded) into your application.

  4. Envelope management and status: Should you include ability to manage envelopes after they’ve been sent, but before they are completed (using Resend, Void, or Correct)?

    • If your integration needs to act as your envelopes are viewed, signed, and completed, you can set up a webhook listener and use Docusign Connect (webhooks) to receive updates when these events occur.
    • To support all Docusign account types (including customer plans purchased from the website), use envelope-level webhooks and our Connect 2.0 event model.

After signing: Do you need to update your application data with information gathered directly from the envelope’s fields? Do you want to store the documents, or leave them with Docusign only?

Best practices

  • Research our REST APIs and documentation before you build: What are the capabilities, limitations, and requirements of Docusign eSignature and other APIs? How do they authenticate, authorize, and communicate with each other?
  • Design the architecture and workflow of the integration: How will the data flow between the services? What are the triggers, actions, and responses? How will you handle errors, exceptions, and retries? What are some common integration patterns that you can use or adapt for my scenario?

Build your solution in the developer environment

Docusign provides a developer environment that enables you to develop and test your app in an environment where it is isolated from production. Creating an account is the first step in getting started with Docusign.

  1. Create a new developer account and use it to develop your integration. Developer accounts are free and do not expire but cannot be used for legally binding agreements.
  2. Simulate connecting customer accounts to your integration and the overall customer experience with an additional developer account.

Recommendation: Ensure that your customers can connect their Docusign developer accounts to your integration as well as to the production environment (incorporate demo.net endpoints and account-d acct server into integration config).

Submit integration to app review process

Once your initial development is complete, you can submit an Application Review to duplicate your integration into the production environment. This application contains:

  • Questionnaire: Provides insight into what the integration is intended to do and how it is implemented to meet its requirements.
  • Solution Listing: A customer-facing description of important integration features and functions, including descriptions of the issues that it solves, its use cases, etc. This is information that will be posted with your integration listing on our Partner finder site.
  • Battlecard information: Contains information about target markets and competitive analysis. Used by Docusign internal teams only.
  • Demo Video: A video recording of a typical walkthrough and presentation of your Docusign integration. Includes how to connect customer accounts via OAuth methods. Submit for Docusign internal teams only.

Your application will be reviewed by our teams and, upon completion, you will receive an ISV Partner Production account. You can then Go Live duplicate your integration into the production environment.

Promote your integration to production using Go-Live

When you are ready to publish your integration into the production environment, use your ISV Partner Production account to duplicate your Integration Key from our demo environment into our production environment. Follow our Go-Live for ISVs process detailed on the developer center.

Next steps