Open-source alternative to the Dropbox Sign API: the short answer
If your application sends signature requests from code and the Dropbox Sign API is billed separately from its web plans, Documenso and DocuSeal can each serve as a self-hosted API replacement, but they fit different integrations. Documenso suits teams that want embedded signing inside their own product, while DocuSeal suits teams that need an API, webhooks and a PDF field builder with a lower entry cost. Documenso's cloud pricing page places API access on its Teams plan and white-labeled embedded signing on Platform, so the self-hosted edition is where you decide which of those capabilities you need. DocuSeal's README lists its API and webhooks as part of the platform, while the pricing page places embedding and bulk send in On-Premises Pro, at $0.20 per completion for embedded signing.
Before you choose, map each API call your application makes to a feature in the candidate platform. Confirm which endpoints create submissions, fetch completed documents, manage templates and receive status callbacks, and whether embedding the signing screen in your own application is required. Check the licensing terms that apply to your use: both projects are AGPL-licensed, and DocuSeal adds Section 7(b) terms, so have counsel review how your application is distributed or offered to users. Confirm the pricing figures with each vendor, since the pages were read in October 2026 and may have changed.
Either option moves responsibility for the signing infrastructure to your team. A self-hosted Documenso operator must supply a signing certificate to digitally sign documents, and the options documented include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS. Both platforms also need outbound email configured so recipients receive invitations and completion notices, and that setup, along with certificate management and key rotation, belongs in your runbook before the first production request.
Which API capabilities map to Documenso and DocuSeal
This table maps the Dropbox Sign API capabilities most integrations use to Documenso and DocuSeal, and marks where licensing or endpoint parity must be confirmed. Read each row against your own integration code, not the summary alone. The main takeaway is that embedded signing and some API features depend on paid tiers or editions, so the licence you choose shapes the integration work.
| Capability | Documenso | DocuSeal |
|---|---|---|
| Create and send signature requests | API access is listed on the Teams plan in cloud pricing. Confirm the same API scope in your self-hosted build. | API is listed as a core feature in the open-source README. Confirm endpoint parity for request creation. |
| Send from reusable templates | Templates exist in the product. Confirm whether the API can create requests from a template ID. | Templates are built in the field builder. Confirm whether the API can send from a template. |
| Embedded signing in your application | Teams includes embedded signing and Platform adds white-label embedding in cloud pricing. Confirm self-hosted terms. | Embedding is not in the free on-premises edition. On-Premises Pro adds it at $0.20 per completion, per the DocuSeal pricing page. |
| Status callbacks | Webhooks are the expected route. Confirm event names and payloads against your current handlers. | Webhooks are part of the open-source feature set. Confirm event coverage for every status you act on. |
| Download completed documents | Confirm whether the API returns the signed PDF for each completed request, and in what form. | Confirm whether the API returns the signed PDF and any attachments in one call. |
| Audit trail retrieval | Confirm whether the audit log is exposed through the API or only through the dashboard. Plan an export if not. | Confirm the audit data available through the API. PDF signature verification is included, but verify its coverage. |
| Document signing certificate | A signing certificate is required for digital signing. Options include a self-signed .p12 or Google Cloud KMS. | Confirm how signed PDFs are secured in your edition and what your assessor will need to see. |
Documenso or DocuSeal for API-driven signing
Both Documenso and DocuSeal can send signature requests from code, receive completion events and keep the signing record on your own servers. They differ in licensing terms, how embedded signing is priced and what each needs from your infrastructure. Check each card against the signing workflows your code depends on before you choose.
Documenso for embedded signing
Documenso is licensed under AGPL-3.0, so the code stays open to read, audit, run and fork. Its API and embedded signing are part of the Teams plan on cloud, and white-labeled embedded signing is part of Platform, so confirm which tier your self-hosted deployment needs before you plan your integration. It runs on PostgreSQL and installs through Docker, Docker Compose, Kubernetes or a manual install. The trade-off is that Documenso requires a signing certificate to digitally sign documents, and you must choose and manage that certificate, such as a self-signed .p12 file or a key held in Google Cloud KMS.
DocuSeal for webhook-driven workflows
DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms, so read the license text with your legal team before you modify or redistribute it. Its API and webhooks are included in the open-source build, which suits teams whose systems react to completion events. It runs on SQLite by default, and PostgreSQL or MySQL can be set through the DATABASE_URL variable for production. The trade-off is that embedded signing requires On-Premises Pro, billed at $0.20 per completion, so model completion volume against a Pro license before you build embedding into a product.
Licensing review for each option
Both projects use AGPL-family licenses, which can require source disclosure when you offer modified software over a network. Your product team should decide whether internal use, customer-facing embedding or a white-labeled product is planned, because that choice changes your obligations. Ask counsel to review the exact license terms for Documenso and DocuSeal, including the DocuSeal Section 7(b) terms, against your planned use before you commit.
Certificate and key ownership
Digital signing depends on a certificate that identifies the organization applying the seal. With Documenso, the operator supplies that certificate, so the key custody decision sits in your hands. Decide where the private key lives, who can rotate it and how you will show an auditor which certificate sealed each completed document. For eIDAS purposes, a qualified electronic signature requires a qualified certificate from a qualified trust service provider, which neither open-source platform issues.
Webhook and callback migration
Existing Dropbox Sign callbacks must be mapped to the event model of the platform you choose, and each event handler must be tested against real completion, decline and expiry flows. Confirm which events each platform sends, how it signs its payloads and how it retries failed deliveries. Keep your receiving endpoint idempotent so a repeated delivery does not create a duplicate record in your system.
Database and operations footprint
Documenso requires PostgreSQL in every deployment, so your team must operate a database with backups, patching and access control. DocuSeal can start on SQLite, which is simple for a pilot, but production use should move to PostgreSQL or MySQL through DATABASE_URL. Ask your platform team who will own upgrades, restores and monitoring, because those duties recur for as long as you run the service.
How per-completion fees change the API cost model
The free on-premises edition of DocuSeal is licensed under AGPLv3 with Section 7(b) additional terms, and its pricing page lists it as free. The license cost is zero, so the recurring costs are the infrastructure you run, the people who maintain it, and the email and certificate services you attach to it. The catch for API users is scope: this edition has no SSO, no bulk send and no embedded signing, so an application that needs signers to complete documents inside its own pages cannot rely on this path alone.
- Recurring: servers or containers, database backups, patching, and staff time for upgrades such as the 3.3.2 release published on October 12, 2026.
- One-time: initial deployment, webhook mapping from existing Dropbox Sign callbacks, and template rebuilding.
- Per-completion fees: none on this path, because the API and webhooks are part of the free edition.
- Feature gap: embedded signing is not included, so confirm whether your product needs it before choosing this path.
- Ask for in a quote: a written list of which API endpoints and webhook events your integration uses, and confirmation that each one works in the free edition.
Before you commit, check your application's signing flow against the feature list on DocuSeal's pricing page.
On-Premises Pro is the path that adds embedded signing, which is the feature most API-driven products need. DocuSeal's pricing page lists it at $240 per user per year, or $20 per user per month billed annually, and adds $0.20 per completion for embedding. The license is a per-user recurring charge, and the completion fee is a usage charge that scales with volume. Both recur, so the model is not a single purchase.
- Recurring license: $240 per user per year, paid for each user who holds a Pro seat.
- Recurring usage: $0.20 per completion for embedded signing, so cost grows with the number of signed documents.
- One-time: deployment, integration work, and a decision on which users need seats.
- Cost drivers: the number of seat holders, the share of completions that run through the embedded flow, and whether bulk send from CSV or XLSX is also needed.
- Ask for in a quote: whether the $0.20 completion fee applies to every completion or only to embedded ones, how completions are counted for multi-signer documents, and whether a volume discount exists.
Check the completion definition in writing, because it determines how the usage charge behaves when a document has several signers.
DocuSeal Cloud is the hosted option, and it prices the API differently. Its Basic plan is listed at $0, while Pro is listed at $20 per user per month. API and embedding usage is billed at $0.20 per completion, and that usage requires at least one Pro seat. This model moves hosting and maintenance to the vendor, but it also moves the signed documents and signer data onto a service you do not operate, which may conflict with a data residency requirement.
- Recurring seat cost: $20 per user per month for at least one Pro seat, which is required before API usage is billed.
- Recurring usage: $0.20 per completion for API and embedding activity.
- One-time: migrating callbacks, rebuilding templates, and confirming data location.
- Cost drivers: the seat count, the completion volume, and whether signing runs through the API or through the web interface.
- Ask for in a quote: where data is stored, which contract terms cover retention and deletion, and how completions are billed when a request is voided or expires.
This path is useful for comparing costs, but it is not self-hosted, so it does not answer the question of who holds the signer data.
Documenso is licensed under AGPL-3.0, so the code is free to run, and its API and embedded signing are available in its Teams and Platform plans on cloud pricing. For a self-hosted deployment, the software license is not the main recurring cost. Documenso also lists an Enterprise plan with custom pricing that is available for cloud or self-hosted setups, and it offers self-hosted licensing options through its self-hosting page. Because the Enterprise terms are negotiated, the cost depends on the written scope rather than on a published per-completion rate.
- Recurring: infrastructure, PostgreSQL operations, backups, and the signing certificate and its renewal.
- One-time: deployment, certificate setup (for example, a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS), and webhook or API migration.
- Per-completion fees: none are listed in the sources for the self-hosted path, so confirm this in writing.
- Cost drivers: whether you need Enterprise support, the number of users, and the operational effort for the certificate and key management.
- Ask for in a quote: whether the Enterprise terms include self-hosted use with embedded signing, what support and upgrade commitments are included, and whether any completion-based fee applies.
Do not assume the cloud Platform price applies to a self-hosted install. Confirm the licensing scope before you build the budget.
Moving existing Dropbox Sign callbacks to webhooks
The first decision is which events your handler actually consumes today. Export the list of callback types your Dropbox Sign integration subscribes to and the fields your code reads from each payload, then map each one to an equivalent in DocuSeal's webhooks or to an event in Documenso's API. Treat this as a mapping exercise, not a find-and-replace: the event names, payload structure and identifiers differ between platforms, so every event name and payload field must be confirmed against the current DocuSeal webhook documentation, Documenso's API reference and your own handler code before any traffic is switched. Keep a written mapping table with one row per event your code depends on, including the fields it reads and what it writes downstream.
Signature verification and retries are where migrations most often fail silently. Confirm how each target platform signs or authenticates outgoing deliveries, what secret or header your handler must check, and whether it can be rotated, then reject any request that fails verification before it touches your database. Also confirm the retry schedule, the number of attempts and what the sender does when your endpoint returns an error, since your handler must tolerate duplicate and out-of-order deliveries. Make the handler idempotent by storing the event identifier or a combination of request ID and event type, and skip events you have already processed. Run both integrations in parallel against a staging environment and compare the records each one produces before cutting over.
Plan the cutover as a short, reversible window. During the overlap, confirm that completed documents still reach the systems that need them, including any handler that downloads the final PDF and audit trail, and that no event is lost when you disable the Dropbox Sign callback. Keep the old callback endpoint enabled until you have seen full event coverage in the new path, and retain logs from both paths as evidence of the migration. If your integration also uses Dropbox Sign's API to create requests or templates, that work belongs to the sibling sections on the API and embedded signing, so scope it separately rather than assuming the webhook move covers it.
Migrating API integrations in sequence
The sequence moves signing requests from Dropbox Sign's API to Documenso or DocuSeal in an order that keeps existing agreements provable, tests every callback before live traffic moves, and leaves a clear record of what changed.
Inventory every API call and callback
Developers list each Dropbox Sign API call your code makes, such as creating signature requests, sending reminders, adding recipients, using templates, and fetching files, along with every callback or event URL your application receives. For each one, record the owning service, the trigger, the data fields it reads and writes, and whether it runs in a web request, a batch job or a scheduled task. The output is a single inventory that maps each Dropbox Sign call to its target equivalent in Documenso or DocuSeal, with gaps marked. Confirm the gaps against the target's current API documentation, since endpoint names and event types differ between the two platforms.
Export completed agreements and audit trails
Before any integration changes, an administrator pulls completed agreements and their non-editable audit trails out of Dropbox Sign, following the export steps on the sibling page on exporting data from Dropbox Sign. Store the files in an archive your records team controls, with the request ID, signer list and completion date kept next to each file so records can be matched later. The check is a reconciliation: the count of exported agreements should match the count of completed requests the API reports for the same period, and a sample should open and show the audit trail intact.
Build templates in the target platform
Recreate each Dropbox Sign template as a template in Documenso or DocuSeal, matching recipient roles, signing order, required fields and merge fields that your code populates. In DocuSeal, this means building fields with the PDF form field builder. In Documenso, it means defining recipient roles and placing fields on the document. Record the template identifier the target platform issues next to the original Dropbox Sign template ID, because the integration code will need both during the transition. The output is a mapping table and a test render of each template with sample data.
Confirm licensing and features for API use
Before the test environment is built, check which features your integration depends on against the target's plan or edition. The researched facts state that Documenso's Teams plan adds API access and embedded signing, and that Platform adds white-labeled embedded signing. For DocuSeal, the free on-premises edition has no SSO, bulk send or embedded signing, while On-Premises Pro adds bulk send, white-label and embedded signing, and API and embedding usage on DocuSeal Cloud is billed per completion. Ask the vendor to confirm which tier covers each feature your inventory lists. The output is a written decision for each feature, so that budget and architecture choices are made before code changes begin.
Run a parallel test environment with test signers
Stand up a non-production instance of the target platform, with its own database, storage and signing certificate, and point a copy of your application at it. For Documenso, this includes setting up the signing certificate the platform needs before it can digitally sign documents. Run the full inventory of calls against the test instance using internal test signers, and exercise each callback path, including declines, expired requests, reminders and completed signatures. The check is a test log showing that every inventory item succeeded or was accepted as a documented difference, and that the audit trail from the test instance can be exported and verified.
Switch callbacks and cut over
Register the target platform's webhook or callback endpoints in the test environment first, then in production once the test log is signed off. Change the application's configuration so new signature requests go to the target platform, and keep the Dropbox Sign callback handler running until no requests remain open on the old platform, so that in-flight agreements still update your system. Watch the first live completions and confirm each one reaches your records store. Tell the reader that the cutover is complete when open Dropbox Sign requests have reached a final state and every callback for them has been processed.
Retain old records and decommission
After cutover, keep the exported Dropbox Sign agreements, audit trails and request mappings in read-only storage under the retention rules your legal and compliance teams set. Remove the Dropbox Sign API keys and callback URLs from application configuration and secrets stores once no open requests remain, and document the date of removal. Store the mapping table from the template step with the archive, so a future auditor or litigator can connect an old request ID to its replacement. The output is a decommission record signed off by the owner of the integration and the records owner.
Running the new signing API beside the rest of the stack
A self-hosted signing service becomes one more system your applications call, and your team now owns the parts Dropbox Sign used to run for you. The four components below connect the signing service to identity, data, storage and operations, and each one needs a named owner before cutover.
Identity for API keys and SSO
Every system that creates signature requests needs a credential, and each credential should map to a named service account rather than a shared personal login. Decide how API keys are issued, rotated and revoked, and who can create them in the signing platform. If your staff sign in to the admin console, confirm whether your identity provider connects through SAML, because DocuSeal's SAML single sign-on sits in its Pro features while its free on-premises edition has no SSO. Confirm the Documenso and DocuSeal API key scopes in your own test environment before you grant any.
Application database for agreement IDs
Your application stores the agreement or document ID returned by the signing API so it can match webhook events and completed files to its own records. Those IDs are the join key between your CRM, contract system or case tool and the signing platform, so they belong in a table you back up and monitor. Documenso uses PostgreSQL, and DocuSeal runs on SQLite by default or on PostgreSQL or MySQL through DATABASE_URL. Pick the engine your operations team already runs, and confirm backups cover the signing database and your mapping table together.
Document storage and retention
Signed PDFs, audit trails and certificates are records you may need to produce years later, so decide where they live and how long they stay. Store completed files in your own object storage or document system, and keep the signing platform's copy as a working copy rather than your only archive. Set retention by record type with your legal team, because the ESIGN Act does not cover every record type, including wills and most family law and court records. Check whether your retention rules override any deletion settings in the signing platform.
Monitoring webhook delivery
Webhooks tell your systems that a signer has viewed, signed or completed a document, and a missed event leaves a contract stuck in pending. Log every inbound event with its document ID, deliver it to a queue your application can replay, and alert when deliveries fail or stop arriving. Test retries by pointing a staging endpoint at the signing platform and forcing a timeout. Decide who receives the alerts, and confirm how the platform retries failed deliveries before you rely on that behavior in production.
Questions teams ask before replacing the Dropbox Sign API
What drives the cost of replacing the Dropbox Sign API with a self-hosted platform?
The main cost drivers are hosting, a signing certificate, the license model and engineering time. Self-hosted Documenso and DocuSeal's free on-premises edition carry no software license fee, but you pay for servers, a PostgreSQL or MySQL database, email delivery and the staff who run it. DocuSeal's On-Premises Pro lists $240 per user per year and $0.20 per completion for API and embedding use, while Documenso's Platform cloud plan lists $250 per month with unlimited users and API. Ask any vendor for a quote that separates one-time setup from recurring license, hosting and per-completion charges.
Does Documenso's API match Dropbox Sign's endpoints?
Do not assume a one-to-one match. Documenso offers API access on its Teams plan and embedded signing on Teams and Platform, so your integration code will need to be mapped to Documenso's endpoints and object model. List every Dropbox Sign call your code makes, including signature requests, templates, webhooks and embedded requests, then check each against Documenso's API documentation in the repository. Build a short test suite that runs the same flows against both systems before you cut over.
Does embedded signing require a Pro or Platform plan?
It depends on the platform. For DocuSeal, the free on-premises edition has no embedded signing, and On-Premises Pro adds it at $0.20 per completion, while DocuSeal Cloud requires at least one Pro seat for API and embedding usage. For Documenso, the pricing page places API access and embedded signing on the Teams plan, and white-labeled embedded signing on Platform. Confirm the exact license terms for your deployment type with each vendor before you commit to a design.
How long does a migration from the Dropbox Sign API take?
The timeline depends on the number of integrations, the number of templates, how many completed agreements must be archived, and how much custom logic sits in your callbacks. A single application that sends a few request types is far simpler than a platform that creates requests from several services. Ask for a written plan that lists each integration, its test cases and its cutover steps, and ask who is responsible for each step. No duration can be given here without that inventory.
Can an internal team migrate from Dropbox Sign by itself?
An internal team can do it if it has people who can deploy containers, manage PostgreSQL or MySQL, configure email and TLS, handle a signing certificate, and rewrite API calls and webhook receivers. The work is less about the signing screens than about the integration code and operations after go-live, such as backups, upgrades and monitoring. Assess those skills honestly. If gaps exist, DeployOpen can plan, implement, integrate and document the platform in your own infrastructure under a fixed-scope written agreement.
What signing certificate does a self-hosted Documenso instance need?
Documenso needs a signing certificate to digitally sign documents. The documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS. A self-signed certificate suits internal testing, but it does not identify the signer in the way a certificate from a trust provider does. Confirm with your legal and compliance teams which certificate type your agreements require before you go live.
What legal effect does the ESIGN Act give electronic signatures, and what does it exclude?
Under 15 U.S.C. 7001(a), a signature, contract or record in or affecting interstate or foreign commerce may not be denied legal effect, validity or enforceability solely because it is electronic. The law has exceptions under 15 U.S.C. 7003, including records governed by laws on wills, codicils and testamentary trusts, state family law such as adoption and divorce, most of the Uniform Commercial Code, and court orders or official court documents. Your counsel should confirm whether your document types fall within these exceptions and whether other laws, such as those in the EU under eIDAS, apply.
Does the ESIGN Act cover API-sent signatures?
The ESIGN Act does not care how a signature request was sent. Under 15 U.S.C. 7001(a), a signature, contract or record relating to a transaction in or affecting interstate or foreign commerce may not be denied legal effect, validity or enforceability solely because it is in electronic form. A signature collected through a Documenso or DocuSeal API call is treated the same as one collected through a web screen, so the sending channel is not the legal question. The question is whether the document type and the signing process meet the requirements that apply to that document. Dropbox Sign makes the same ESIGN-based claim on its pricing page, so a migration does not change the underlying legal basis by itself.
The exceptions matter more for API workflows because code can send any document type at scale. Under 15 U.S.C. 7003, the ESIGN Act does not reach records governed by laws on wills, codicils and testamentary trusts, most state family law matters such as adoption and divorce, most of the Uniform Commercial Code, or court orders and official court documents. An integration that auto-generates these document types from a CRM or case system needs a filter that routes them out of e-signature, or a documented decision that a wet-ink or other process applies. Confirm the exclusions against your state's law with counsel. If you sign with European counterparties, eIDAS is a separate question. Simple signatures carry no assurance level by default, while advanced (AdES) signatures must let the signatory keep control and make later changes detectable. Qualified signatures require a qualified certificate from a qualified trust service provider listed in a national Trusted List, which an open-source platform does not supply on its own. Ask counsel and any relying party which level they need, and confirm with the chosen trust provider how certificates would reach your API integration before you commit to a design.
How DeployOpen scopes and delivers an e-signature API replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For an API replacement, that means working from your current Dropbox Sign request flows and callbacks to a Documenso or DocuSeal deployment that your team operates in its own cloud account, data center or air-gapped network.
How we scope
- Inventory every Dropbox Sign API call, template ID, callback URL and embedded signing flow your products depend on
- Decide between Documenso's API and embedded signing and DocuSeal's API and webhooks, with the license and plan needed for each
- Agree in writing whether signing certificates, eIDAS levels and retention rules are in or out of scope
How we build
- Deploy the chosen platform with Docker or Kubernetes and PostgreSQL in your environment, using your identity and email setup
- Re-map callbacks to Documenso or DocuSeal webhooks and test each event your integrations consume end to end
- Run security testing on the integration layer, including API authentication, webhook signature checks and access to stored documents
How we hand over
- Provide documentation for deployment, configuration, API integration, backups and upgrade steps your engineers will follow
- Walk your platform and application teams through the running integration and the operational runbook
- Deliver the export of prior completed agreements and audit trails in the formats agreed during scoping
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Ask any quote to itemize setup, integration, testing, documentation and retainer effort separately from license or hosting costs
