DocuSign retired basic user password authentication on September 30, 2024, ending support for the X-DocuSign-Authentication header that integrations had relied on since the early days of the eSign REST API. Any team still sending that header had to rebuild its auth layer on OAuth 2.0, where DocuSign supports three grant type families (Authorization Code, split into confidential and public variants, plus JWT and Implicit).
Most of those migrations shipped under deadline pressure, so the quickest path usually won and teams re-authenticated against DocuSign without weighing anything else. That forced work is now behind you, and nothing is forcing the next decision, which makes this a better moment to ask whether DocuSign still fits your SaaS application or whether another e-signature API serves it better.
This guide applies a consistent technical framework to six alternatives, evaluating each against five criteria (authentication model, embedded signing implementation, SDK language coverage, webhook event reliability, and compliance footprint) to give you a decision matrix you can act on.
Five technical criteria that drive the right choice
These five dimensions determine whether an API works in production, not just in a proof of concept. Each one maps to a real constraint you'll hit during integration.
OAuth2 grant type support. Most e-signature APIs support Authorization Code Grant for user-delegated flows and client_credentials for server-to-server automation. Embedded SaaS workflows typically run server-side, without a human in the auth loop at signing time. An API that requires Authorization Code Grant for every token request adds friction to automated pipelines.
Embedded signing model. The divide between iFrame embedding and redirect-based signing determines whether your signers ever leave your application. Redirect-based flows push users to a third-party domain, then return them via a callback URL. iFrame embedding keeps the signing UI inside your product's chrome. For SaaS teams building a white-labeled experience, iFrame is the stronger choice, but it requires the API to generate a signed session URL with correct CORS headers and sandbox attribute permissions.
SDK language coverage. An API without an SDK in your stack adds overhead, because you build and maintain HTTP clients, handle retry logic, and parse response schemas manually. SDK coverage signals how seriously a vendor treats developer experience at the integration layer.
Webhook event schema and reliability. Envelope status changes (signed, declined, voided) need to reach your application reliably and in a verifiable format. Webhook payloads vary across providers in schema structure, authentication method (HMAC-signed vs. unsigned), and retry behavior on delivery failure. A provider that signs payloads with HMAC and retries on failure is safer to build against than one that delivers once with no retry guarantee.
Compliance footprint. Your legal and security teams will flag this regardless. ESIGN and UETA cover US enforceability. GDPR applies whenever signers are EU residents. HIPAA and FDA 21 CFR Part 11 are hard requirements in healthcare and life sciences. Identify the standards your contracts and signers require before you run your first sandbox test.
Embedded signing alternatives
Foxit eSign
Foxit eSign uses the OAuth2 client_credentials grant, which works well for server-to-server SaaS workflows. You POST your client_id and client_secret to the regional OAuth2 endpoint to exchange credentials for a Bearer token. Foxit routes requests to regional infrastructure, with na1.foxitesign.foxit.com for US-hosted data and eu1.foxitesign.foxit.com for EU. Every subsequent API call carries that token in the Authorization: Bearer header.
The iFrame embedding model uses two parameters on the Create Envelope call. Setting createEmbeddedSigningSession to true suppresses email delivery and generates a session token. Setting createEmbeddedSigningSessionForAllParties to true generates individual signed URLs for each recipient. The resulting URL takes the form https://HOST_NAME/embedded/embeddedsign?eetid={URL-ENCODED-TOKEN}, which you drop into an <iframe> tag inside your application. After a recipient signs or declines, Foxit eSign redirects to the return URL you specified in the Create Envelope request, appending folderId and an event parameter (signing_success or signing_declined), so your application can act on the outcome without polling.
Published API sample code covers cURL, PHP, C#, and Java. Webhook channels fire on envelope status changes including EXECUTED, and you can configure a webhookSecret so your endpoint can validate HMAC-signed delivery payloads. The compliance footprint covers ESIGN, UETA, GDPR, HIPAA, CCPA, and FDA 21 CFR Part 11, making Foxit eSign viable for healthcare and life-sciences workflows that require Part 11 audit trails and long-term record validation.
A free developer account is available at app.developer-api.foxit.com/sign-up with no credit card required. Full API reference lives at docs.developer-api.foxit.com. For current plan pricing, see the Foxit eSign API credits page.
Dropbox Sign
Dropbox Sign (formerly HelloSign) supports OAuth2 Authorization Code Grant alongside API key authentication. For embedded signing, the API generates a sign_url via an embedded signing request. You render that URL inside an iFrame using Dropbox Sign's JavaScript client library, which manages the signer handshake and posts completion events back to the parent page.
Official SDKs cover Node, Python, Ruby, Java, PHP, and .NET. Webhooks deliver signature request events validated via a callback hash. The compliance footprint includes ESIGN, UETA, GDPR, and HIPAA, though HIPAA support requires an annual Standard or Premium plan plus a signed Business Associate Agreement rather than being available on every tier. A free Test mode plan lets you build and exercise the full API before committing, with paid tiers starting once you send live signature requests. For current plan details, see the Dropbox Sign API pricing page.
Dropbox Sign's embedded model requires loading the JavaScript SDK in the parent page, adding a client-side dependency. Teams that want a purely server-rendered iFrame approach without a JS dependency will find that coupling inconvenient, particularly in server-side-rendered stacks where loading a third-party client script creates CSP friction.
SignNow
SignNow, an airSlate product, supports the OAuth2 password, refresh_token, and authorization_code grants, where the authorization code grant covers applications acting on behalf of an individual SignNow user rather than the signing flow itself. Embedded signing runs on a bearer token or API key, so the signer never touches OAuth. You create an embedded invite via the API, generate a link for that invite, then render it in an iFrame inside your application.
SignNow publishes SDKs for PHP, .NET, Java, Python, and Node.js, with an Android SDK added more recently. Compliance certifications cover ESIGN, UETA, HIPAA, GDPR, and SOC 2 Type II, alongside 21 CFR Part 11, PCI DSS, eIDAS, and CCPA. For developer plans, see the SignNow API pricing page.
The webhook layer delivers user, document, and document_group events, and you can have them HMAC-signed by supplying your own secret when you create the subscription, which arrives as an X-SignNow-Signature header holding a base64 HMAC-SHA256 digest. Signing is opt-in rather than the default, so an integration that skips the secret receives unauthenticated callbacks. Recipient identity verification is configured per recipient on the invite and offers a password, an SMS code, or a phone-call code.
Document automation and open-source alternatives
DocuSeal
DocuSeal is an open-source e-signature platform designed for self-hosting, making it the primary option for teams with strict data-residency requirements. Documents stay inside your infrastructure rather than transiting a third-party cloud. The API authenticates with an API key sent in a custom X-Auth-Token header rather than an Authorization: Bearer header, which is the one place a migration script written against the other providers in this guide needs a different code path. The embedded signing UI ships as a <docuseal-form> JavaScript web component, with official React, Vue, and Angular wrappers you mount in your front end.
The open-source repository is available on GitHub under AGPLv3 with additional attribution terms, and a managed cloud version is also offered. First-party SDKs cover Ruby, JavaScript and TypeScript, Python, PHP, Java, C# and .NET, and Go, so the self-hosted path is not limited to the two languages the project started with. Because you control the infrastructure, you control data location, which addresses GDPR data-residency obligations that cloud-only providers cannot satisfy without a Data Processing Agreement and region-locked storage commitments. For cloud pricing and self-hosting configuration details, see the DocuSeal pricing page.
Read that compliance list with the deployment model in mind. The SOC 2 Type II and ISO 27001 certifications cover DocuSeal's own managed cloud, so when you self-host, the audit evidence for your environment becomes your responsibility rather than the vendor's. Running self-hosted signing infrastructure also means your team owns uptime, secret key management, and upgrade cycles, and that operational burden is the direct trade-off for the data control DocuSeal provides.
BoldSign
BoldSign targets SaaS developers embedding signing into customer-facing products. Authentication supports OAuth2 (client_credentials and Authorization Code Grant) and API key. The embedded signing flow generates a signed URL you render in an iFrame, with no client-side JS SDK dependency required.
Official SDKs are published for .NET, Java, Python, Node.js, and PHP. Webhooks fire on document status events and support HMAC-signed payload validation. The compliance footprint covers ESIGN, UETA, HIPAA, and GDPR, though HIPAA support sits on the Business tier rather than the entry plans. A genuinely free plan is available rather than a time-boxed trial. For full plan details, see the BoldSign pricing page.
BoldSign's API documentation covers the full envelope lifecycle with code samples across its published SDK languages, and the free plan's limits make it a workable tier for integration testing without a time-boxed trial window.
PandaDoc
PandaDoc covers a wider scope than pure e-signature. The platform addresses full document automation, including template management, proposal generation, and CPQ (configure, price, quote) document creation, with e-signature as one output in that pipeline. The API supports OAuth2 Authorization Code Grant and API key authentication. Embedded signing runs on a session URL, which PandaDoc now recommends rendering through its pandadoc-signing client library rather than wiring the iFrame by hand.
Official client SDKs are published for Python, Node, Java, and PHP, with Ruby and .NET available only as community-maintained wrappers. Webhooks fire on document events with callback validation. The compliance footprint includes ESIGN, UETA, HIPAA, GDPR, and SOC 2 Type 2, though transmitting protected health information requires signing a Business Associate Agreement with PandaDoc rather than relying on the platform default. Sandbox API calls are free of charge for development, though the sandbox key itself is only available on the Business or Enterprise plan, and a production key requires Enterprise plus manual activation by PandaDoc, so factor both gates into any timeline. For current rates, see the PandaDoc pricing page.
Teams that need document generation, CRM-driven template population, and signing in a single workflow will find the broader platform scope worth the integration surface area. Teams evaluating PandaDoc for e-signature alone should factor in that breadth before committing, since it drives both API complexity and plan cost.
Comparison at a glance
| Tool | Auth Model | Embedded Signing | SDK Languages | Compliance | Free API Tier |
|---|---|---|---|---|---|
| Foxit eSign | OAuth2 client_credentials
|
iFrame via createEmbeddedSigningSession
|
cURL, PHP, C#, Java | ESIGN, UETA, GDPR, HIPAA, CCPA, FDA 21 CFR Part 11 | Yes (no credit card; 30-day trial in test mode) |
| Dropbox Sign | OAuth2 + API key | iFrame + JS client library | Node, Python, Ruby, Java, PHP, .NET | ESIGN, UETA, GDPR, HIPAA (Standard/Premium plan + BAA) | Yes (free Test mode) |
| SignNow | OAuth2 (password, auth code, refresh) + API key | iFrame via embedded invite | PHP, .NET, Java, Python, Node.js, Android | ESIGN, UETA, HIPAA, GDPR, SOC 2, 21 CFR Part 11, eIDAS | Yes (free Dev Mode test tier) |
| DocuSeal | API key (X-Auth-Token) |
iFrame (web component) | Ruby, JS/TS, Python, PHP, Java, C#/.NET, Go | ESIGN, UETA, eIDAS, GDPR, HIPAA, 21 CFR Part 11, SOC 2, ISO 27001 | Yes (open source / limited cloud) |
| BoldSign | OAuth2 + API key | iFrame | .NET, Java, Python, Node.js, PHP | ESIGN, UETA, HIPAA, GDPR | Yes (free plan) |
| PandaDoc | OAuth2 Auth Code + API key | iFrame via pandadoc-signing
|
Python, Node, Java, PHP | ESIGN, UETA, HIPAA (BAA), GDPR, SOC 2 | Sandbox calls free (Business/Enterprise plan); production requires Enterprise |
Verify all cells against each vendor's current documentation before making a selection, as SDK and compliance details change with platform updates.
How to migrate from DocuSign to a new API
The five steps below apply regardless of which alternative you choose. Each step is designed to be verified in isolation so you catch provider-specific behavioral differences before touching production.
flowchart LR
A[Generate<br/>OAuth2 Credentials] --> B[Test Token<br/>Exchange in Sandbox]
B --> C[Repoint<br/>Authorization<br/>Header]
C --> D[Remap Webhook<br/>Event Payloads]
D --> E[Swap SDK<br/>Dependency]
E --> F[Run Test Suite<br/>Against New Sandbox]Step 1. Generate new OAuth2 credentials.
Every provider in this guide uses a client_id and client_secret as the starting point. Create a sandbox account, retrieve your credentials from the developer portal, and export them as environment variables so they never end up in your shell history or a committed file. Then use Postman or a direct cURL call to confirm you can exchange them for a Bearer token. For a client_credentials flow such as Foxit eSign, the request looks like this:
curl --location "https://$REGIONAL_ENDPOINT/api/oauth2/access_token" --header 'Content-Type: application/x-www-form-urlencoded' --data-urlencode 'grant_type=client_credentials' --data-urlencode "client_id=$CLIENT_ID" --data-urlencode "client_secret=$CLIENT_SECRET" --data-urlencode 'scope=read-write'
In this command, you post your credentials to the provider's token endpoint as a form-encoded body rather than JSON, which matters because Foxit eSign rejects a JSON body on this endpoint with HTTP 415. The grant_type and scope values tell the provider you want a server-to-server token with read and write access. Read the credentials from $CLIENT_ID and $CLIENT_SECRET in your environment so the values stay out of the command itself.
A successful exchange returns the token alongside its type and remaining lifetime:
{"access_token":"REDACTED","token_type":"bearer","expires_in":23480263,"instance_url":"https://na1.foxitesign.foxit.com/"}
The instance_url confirms which regional host issued the token, and every call you make afterwards sends Authorization: Bearer <access_token> against that same host.
For Authorization Code flows (Dropbox Sign, SignNow, PandaDoc), follow that provider's OAuth2 redirect sequence to obtain your initial token. Confirm the token arrives before writing any application code.
Step 2. Repoint the Authorization header at your new provider.
Since the legacy header stopped working in 2024, your DocuSign integration already sends an OAuth 2.0 Bearer token:
Authorization: Bearer {DOCUSIGN_ACCESS_TOKEN}
Every provider in this guide uses that same header shape, so what changes is which service issued the token, not how you attach it:
Authorization: Bearer {ACCESS_TOKEN}
That makes the transport change small and the token-acquisition change the real work, which is why Step 1 comes first. If your codebase predates the retirement, grep for X-DocuSign-Authentication as well and delete any leftover credential-construction logic that still assembles the old JSON payload, since that code is dead and only obscures which auth path is live.
Step 3. Remap webhook event payloads.
DocuSign's Connect service uses its own envelope status event schema. Your new provider uses a different schema with different field names, status strings, and nesting. Map the fields your current handler consumes (envelope ID, signer email, completion timestamp, event type) to the new provider's equivalent fields. Build a translation layer that converts the new provider's payload into the shape your downstream code already expects. This approach keeps your business logic untouched and isolates the mapping delta to a single module you can test independently.
Step 4. Swap the SDK dependency.
Remove the DocuSign SDK from your package manager and install the equivalent SDK for your new provider. Compile-time errors and type mismatches surface immediately. Work through them method by method, keeping business logic (what you do with a completed envelope) separate from transport logic (how you call the API), so the two don't share state.
Step 5. Run your existing test suite against the new sandbox.
Your existing integration tests should pass against the new provider's sandbox before you touch production. Any test that fails points to a schema delta or a behavioral difference you need to handle explicitly. Fix the underlying mismatch rather than disabling the test.
The three variables that actually decide
Your embedded signing model (iFrame vs. async redirect), your required SDK language coverage, and your compliance obligations are the three variables that determine the right e-signature API for your stack.
DocuSeal is the right answer when data residency and self-hosted control are non-negotiable. PandaDoc fits teams that need document automation alongside signatures as part of a single pipeline. BoldSign and Foxit eSign both target embedded SaaS use cases, with BoldSign standing out for a free tier that sends real envelopes rather than test-only traffic, and Foxit eSign covering the regulated-industry compliance surface (including HIPAA and FDA 21 CFR Part 11) that healthcare and life-sciences teams require.
Read the free tiers carefully, because they are not equivalent. Dropbox Sign's Test mode and SignNow's Dev Mode give you an unlimited test environment but no live signatures, PandaDoc's sandbox is free while production is gated behind the Enterprise plan, and Foxit eSign's self-serve developer activation provisions a 30-day trial in test mode with watermarked envelopes before production access goes through Foxit. BoldSign's free plan is the outlier, allowing a small monthly volume of genuine envelopes. A tier that looks generous in a comparison table can still stop at the exact moment you want to ship.
If Foxit eSign's iFrame-embedded model and compliance depth fit your stack, the free developer account at app.developer-api.foxit.com/sign-up gives you API keys and a full sandbox environment with no credit card required.
Which of the five evaluation criteria is the hardest constraint in your current stack? Share in the comments.
Top comments (0)