Embedding e-signature in your own application: why the product team's choices matter more than the signing tool
A SaaS or platform team that wants signing inside its own product flow faces a different decision from an internal team buying a signing tool for staff. Both Documenso and DocuSeal expose an API, webhooks and embedded signing, but whether you can embed, white-label and avoid per-completion fees depends on the edition you run. The signing engine is only part of the design. The edition, its license terms and the way your application calls the API determine what your customers see and what you pay as volume grows.
Internal signing lets a team accept a vendor's interface as it is. Embedded signing puts the signing step inside your product, often under your brand and tied to your user accounts and records. That shifts the questions to the product side: who creates the envelope, how the signer is authenticated before the link opens, which events drive your own state changes, and how completed files return to your data store. In the editions reviewed, DocuSeal's free on-premises edition has no embedded signing, and its Pro edition adds white-label and embedded signing with a per-completion charge of $0.20. Documenso's Teams plan adds API access and embedded signing, and its Platform plan adds white-labeled embedded signing. Confirm these tier boundaries against the current pricing pages before design starts, because they change.
Our short answer for a platform team is this: pick the edition that covers embedding and white-labeling your product needs first, then model per-completion fees against your expected completions, and only then design the integration. Ask for the license text, confirm how AGPL-3.0 obligations apply if you modify the signing code and expose it to your users over a network, and write these answers into the scope before development begins. Illustrative example: a platform that sends a few thousand agreements a month may find per-completion fees matter more than the license fee, so the edition decision needs the volume estimate first.
Which requirements shape an embedded signing build
This table lists the requirements that follow from licensing, edition gating, signing certificates, database choice and webhook behavior when signing is embedded in your product. Read each row as a decision: what it changes in the build and what to confirm with the vendor before you commit to a design.
| Requirement | What it means for the build | What to confirm with the vendor |
|---|---|---|
| AGPL-3.0 licensing (Documenso and DocuSeal) | Both projects are AGPL-3.0. If you modify the signing code and offer it to users over a network, the AGPL source obligations for those modifications apply, so your product team must decide early how far customizations go. | Confirm with counsel how the AGPL applies to your architecture, including whether embedding through the API keeps your application outside the modified-code scope. |
| DocuSeal Section 7(b) additional terms | DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms. These terms can add attribution or branding conditions that the build must preserve, so review them before changing the interface. | Ask the vendor to state the attribution and notice requirements that apply to your white-labeled or embedded deployment. |
| Edition gating for API and embedded signing | API and embedded signing are not free features in every edition. The edition you license determines whether your product can call the API or embed the signing experience, so the plan must match the feature set your product needs. | For Documenso, confirm which plan includes API access and embedded signing for self-hosted use. For DocuSeal, confirm that embedding is included in On-Premises Pro. |
| White-label and branding | White-labeled embedded signing is gated to higher editions. Product teams should plan branding, domains and signer-facing messages around the license tier rather than assume they can be changed in any setup. | Ask which white-label features apply to self-hosted editions, and whether custom domains and email templates are covered. |
| Per-completion API fees (DocuSeal) | DocuSeal's embedding and API usage is billed per completion on its cloud plans, while on-premises Pro lists a per-completion rate for embedding. Volume forecasts must count completions, not only users, when you compare options. | Ask for written confirmation of which completion charges apply to your deployment model and how completions are counted. |
| Signing certificate requirement | Documenso needs a signing certificate to digitally sign documents. Options include a self-signed .p12 certificate generated with OpenSSL or signing through Google Cloud KMS, so key custody and rotation must be designed before launch. | Confirm which certificate type is appropriate for your signing level and who issues and rotates the certificate, and whether DocuSeal requires a comparable setup for your use. |
| PostgreSQL or MySQL for production | DocuSeal runs on SQLite by default, while PostgreSQL or MySQL is set through DATABASE_URL. Documenso uses PostgreSQL. A production embedded service needs a managed, backed up and monitored database rather than the default file-based setup. | Confirm the supported database versions for your chosen release and the backup and restore method for signed documents and audit records. |
| Webhook-driven state sync | Your application should not poll for signing status. Build a webhook receiver that updates your records on completion, decline or expiry, verifies the sender, handles retries and stores events idempotently so duplicate deliveries do not create duplicate states. | Ask how webhooks are signed, how retries behave, and which document events are emitted, including declined and expired envelopes. |
Documenso or DocuSeal for embedded signing: which fits your product
Both platforms can sit behind your product, but embedding, white-labeling and per-completion fees are gated differently by edition. The cards below set out where each one starts to fit, what it costs to run, and what to confirm before you commit to an edition.
Documenso Teams for API and embedding
Documenso's Teams plan adds API access and embedded signing, which is the entry point for a product team that wants signing inside its own screens. Check whether the Teams seat model matches your number of internal users, since the plan is priced per seat. Confirm with Documenso which features on the Teams plan match your embedding design before you build against them, because the plan boundary determines what your customers see.
Documenso Platform for white-label signing
Documenso's Platform plan adds white-labeled embedded signing, so the signing experience can carry your brand rather than Documenso's. This matters when signers are your customers and the signing page is part of your product. Ask whether white-labeling extends to signer emails and completion certificates, since those are also seen by your customers and may need the same treatment.
DocuSeal On-Premises Pro for per-completion pricing
DocuSeal On-Premises Pro adds white-label and embedded signing, with API and embedding usage billed at $0.20 per completion. Your cost then tracks signing volume rather than seat count, which suits products where many signers are external. Model completions per month against the per-user license, and confirm whether any per-completion charge applies to self-hosted deployments the same way it applies to cloud usage.
Free DocuSeal edition has no embedding
The free DocuSeal on-premises edition has no embedded signing, no white-label and no API-based embedding path. A team that prototypes on the free edition will need to rebuild its integration once it moves to Pro. Plan the embedding design on the paid edition from the start, and test your webhook and signing-link flow on it before the rest of the product depends on it.
AGPL obligations for modified code
Documenso and DocuSeal are both distributed under AGPL-3.0, and DocuSeal adds Section 7(b) additional terms. If you modify either platform and offer it to users over a network, the AGPL source obligations can reach your changes. Have counsel review the license text and any Section 7(b) terms against your planned customizations, and decide early whether changes stay internal, are contributed back or sit in a separate service.
Signing certificates for your product
Documenso needs a signing certificate to digitally sign documents, and documented options include a self-signed .p12 certificate created with OpenSSL or signing through Google Cloud KMS. A product that issues signed documents to many customers needs a certificate strategy that your customers and their auditors will accept. Confirm the certificate type, its issuer and key custody with your implementation partner before go-live.
What AGPL-3.0 requires when you modify a signing platform
AGPL-3.0 is a copyleft license with a network-use clause, so if you modify Documenso or DocuSeal and let users reach that modified version over a network, you may have to offer them the corresponding source code of your changes. Documenso is licensed under AGPL-3.0, and its README says the code stays open source to read, audit, run and fork. That freedom comes with the obligation to pass the same terms on to anyone who uses your modified version through a network, including your customers signing documents in your product. Running an unmodified copy for your own internal use is a different situation from shipping a changed signing flow, branded screens or custom fields to external users.
DocuSeal is distributed under AGPLv3 with *Section 7(b) additional terms*, and those terms change what you may do with attribution and branding. Read them in full from the DocuSeal repository before you alter the interface, remove notices or white-label the product, because the additional terms can add conditions beyond the base license. The Pro features in its README, including company logo and white-label and embedded signing, are sold under a separate commercial license, so confirm which edition's terms govern each feature you plan to use. Ask your licensing counsel to map each modification to a specific license term rather than assuming that a paid edition removes the source obligation.
Calling the signing API from your application is a separate case from modifying the platform itself. If your product sends documents to an unmodified Documenso or DocuSeal service over its API and webhooks, your own code is generally a separate program that communicates with it, but the boundary depends on how tightly the pieces are coupled, whether you copy or embed platform code, and whether you change the platform's templates or pages. Document the architecture, list every fork or patch, and have a licensing or legal review confirm the position for your product before launch. This section is general information, not legal advice.
Three ways to deploy embedded signing for a product
In this pattern, the SaaS vendor runs one signing instance for all of its customers, and your application calls it through the API. Your team does not operate the database, container images or upgrades, but the vendor controls where signed records and signer data are stored and how tenants are separated. Settle these questions before you commit to this path, because they are hard to change later.
- Data residency: Ask which regions host the instance and whether signed PDFs, audit records and signer data stay in those regions, including backups.
- Database operation: The vendor runs PostgreSQL or MySQL for all tenants, so ask how tenant data is separated and who holds restore rights.
- Certificate ownership: Confirm whether one signing certificate is shared across tenants or assigned to your account. Documenso's documented options include a self-signed .p12 certificate generated with OpenSSL and signing through Google Cloud KMS.
- Webhook reachability: The vendor must reach your public HTTPS endpoint to deliver completion events, so plan retries and signature verification on your side.
- Licensing: Documenso's Teams plan adds API access and embedded signing, and its Platform plan adds white-labeled embedded signing. If your product modifies AGPL-3.0 code and offers it to users over a network, the source obligations apply to that modified code.
Confirm the tenancy model, hosting regions and data export path in writing before you sign a contract.
Here, each customer receives its own signing instance in its own cloud account, so the customer chooses the region and controls the data path. Your product team provisions and supports the deployment, while the customer keeps the signed records inside its own boundary. This pattern suits customers whose contracts require tenant-level isolation, and it adds operating work for every instance you run.
- Data residency: Each instance sits in the region the customer selects, which makes residency a per-customer configuration rather than a platform-wide setting.
- Database operation: Documenso uses PostgreSQL. DocuSeal runs on SQLite by default and can use PostgreSQL or MySQL through the DATABASE_URL variable, so choose the database before production load begins.
- Certificate ownership: The customer holds the signing certificate, either as a self-signed .p12 file or through Google Cloud KMS, and that choice determines who rotates and revokes it.
- Webhook reachability: The instance makes outbound calls to your application, so confirm egress rules, allowed endpoints and retry behavior for each customer network.
- Licensing: Documenso is licensed under AGPL-3.0. DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms. Its On-Premises Pro edition lists $240 per user per year and $0.20 per completion for embedding, and its free edition has no embedded signing.
Confirm the per-instance licensing count, upgrade responsibility and certificate rotation process before you promise a rollout date to a customer.
In this pattern, the signing service runs inside a customer's private network, which may have no direct route to the public internet. Your application and the signing service communicate on internal addresses, and images, updates and certificates arrive through channels the customer approves. This pattern carries the most design work because each external dependency must be checked against the network policy.
- Image supply: Official images are published on Docker Hub and GitHub Container Registry. Confirm how the customer mirrors images into an internal registry and how it receives updates.
- Database operation: The customer's team, or a partner acting under contract, runs PostgreSQL or MySQL inside the enclave, with backups stored under the customer's policy.
- Certificate ownership: Google Cloud KMS requires connectivity to a cloud service, so a disconnected deployment typically relies on a self-signed .p12 certificate generated with OpenSSL. Confirm this against the customer's certificate policy.
- Webhook reachability: Webhooks should target internal services only. Test that every callback resolves and that signature checks succeed without public DNS.
- Licensing: Embedded signing appears in Documenso's Teams and Platform plans and in DocuSeal's On-Premises Pro edition, so confirm the edition and the per-completion fee before the design is fixed.
Verify the complete list of external calls, image sources and certificate steps against the customer's network policy before any installation begins. The Documenso signing documentation is the starting point for certificate options.
Rollout phases for an embedded signing integration
This sequence moves a signing integration from licensing decision to production, with a named output at each phase so the product, legal and security teams can sign off before code reaches customers.
Confirm edition and licensing
Product, legal and procurement confirm which Documenso or DocuSeal edition includes the API, embedded signing and white-labeling your product needs. Compare the cloud plans, the self-hosted editions and any per-completion fees against your expected volume. Ask the vendor in writing which features are included in each edition and whether embedding is licensed per user, per completion or both. The output is a licensing memo that names the edition, the fee model and the features each team depends on.
Review AGPL obligations and modifications
Engineering and counsel review how the AGPL-3.0 license applies to your architecture, especially if you modify the signing platform, expose it to users over a network, or combine it with proprietary services. Decide whether you will change the upstream code or keep it unmodified and integrate only through the public API. Document any DocuSeal Section 7(b) additional terms that counsel needs to read. The output is a signed modification policy and a list of components that will or will not be changed.
Set up environment and database
Platform engineering deploys the chosen signing platform in staging with the agreed container method, such as Docker Compose or Kubernetes, and connects it to PostgreSQL or MySQL where your edition requires it. Confirm the database choice before go-live, because the default storage in some setups differs from production needs. Set secrets management, backups and network paths between your application and the signing service. The output is a reproducible staging environment built from configuration under version control.
Configure the signing certificate
Security and platform teams choose how the platform will apply digital signatures, such as a self-signed .p12 certificate generated with OpenSSL or a key held in a cloud key management service. Document who owns the private key, how it is rotated and how it is backed up. Test that signed PDFs validate in a standard reader and that the certificate chain matches your policy. The output is a signed certificate decision record and a verified sample signed document.
Design the API and embedded session
Solution architects define how your application creates documents, assigns recipients, passes signer identity and receives completion status. Decide whether signers see the embedded session inside your product or receive an emailed link, and how session tokens expire. Map each signing action to your own user and tenant model so that access control stays in your application. The output is an approved architecture diagram and API contract that security has reviewed.
Build webhook handling with idempotency
Backend engineers implement the endpoint that receives signing events and update the record of each document in your system. Each event must be processed once even when the sender retries, so store event identifiers and make state changes idempotent. Verify each webhook's authenticity before processing and log rejected requests. The output is a tested webhook handler that passes replay and duplicate-delivery tests in staging.
Apply white-label and branding
Product and design teams apply logos, colors, sender names and signing page text in line with the edition that supports white-labeling. Confirm which branding elements appear in signer emails, signing pages and completed documents, and review them against your legal notice requirements. Check the result in each supported language and on mobile devices. The output is an approved brand configuration and a set of screenshots reviewed by the product owner.
Test end to end with signer email
QA and engineering run complete signing journeys, from document creation through signer invitation, signing, completion and webhook update, using test mailboxes across the major providers your customers use. Confirm that invitation emails arrive, are not filtered as spam, and that expired links fail safely. Include failure cases such as declined signatures, voided documents and unavailable webhook endpoints. The output is a test report that lists every journey, its result and any open defect.
Go live with monitoring
Operations deploys to production through the same pipeline used in staging and enables monitoring for signing delivery, webhook failures, certificate expiry and database health. Set alert owners and a documented response path for each alert. Confirm that support staff have runbooks for resending invitations and reprocessing failed events. The output is a production release record and a monitoring dashboard that the on-call team has tested.
Evidence a product customer or auditor will ask the signing flow to produce
This table maps each piece of evidence a customer, security reviewer or auditor typically asks for to the component that produces it in a self-hosted Documenso or DocuSeal deployment. Read each row as a question to answer before launch: what artifact exists, where it lives, and who keeps it. DeployOpen prepares these records and configuration, but independent auditors and certification bodies decide whether they meet a given assessment.
| Evidence | Where it comes from | What to confirm before launch |
|---|---|---|
| Signed PDF with signature details | Signing certificate configured for the platform (self-signed .p12 or a cloud KMS key), applied at completion | Which certificate signs, who controls its private key, and that signature validation works in external PDF readers |
| Audit trail of signer actions | Platform event log recording views, field entries, consent and completion for each envelope | That the trail covers every action your customer relies on, and how long records are retained in your database |
| Webhook delivery logs | Webhook configuration and delivery attempts from the signing API to your application | Retry behavior on failed deliveries, and whether your system stores received events for reconciliation |
| API access logs | Reverse proxy or gateway logs plus application logs for requests that create, send or read documents | That logs capture caller identity, timestamp and document ID, and that they ship to a store your team can search |
| Database backups | PostgreSQL (or MySQL) backups holding envelopes, signer records and audit events | Backup schedule, encryption, restore test results and whether restores include stored signed files |
| Certificate configuration record | Configuration files, secrets references and change history for the signing certificate or KMS key | Who approved each certificate change, rotation procedure, and where the private key or KMS policy is documented |
| White-label and branding settings | Platform settings for logo, domain and embedded signing presentation, kept under version control | That branding changes are reviewed, and that signer-facing domains and emails match what your customer contract describes |
| Licensing and edition record | Edition purchased, license terms and the AGPL-3.0 source reference for any modified code you run | Which edition covers embedding and white-labeling, and whether your modifications must be published under AGPL-3.0 |
Questions buyers ask before hiring help to embed signing
What does it cost to embed e-signature in our product?
The cost has two parts: one-time effort to build and test the integration, and recurring platform and usage fees. The effort covers the signing flow inside your interface, webhook handling for status changes, storage of completed PDFs, error handling and testing against your own document types. The recurring side depends on the edition. Documenso's pricing page lists Teams at $40 per month for 5 users plus $8 per extra user, and Platform at $250 per month with unlimited users and API, while its Enterprise plan is custom priced. On the DocuSeal side, On-Premises Pro is $240 per user per year, and embedded signing usage is $0.20 per completion. Ask any partner for a fixed-scope quote that separates one-time work from each recurring fee, and confirm current prices on each vendor's pricing page before budgeting.
How long does a signing integration take to build?
Duration depends on scope, not on the signing engine alone. The main drivers are the number of document types and templates, whether signers need an embedded experience inside your app or only an emailed link, how many systems must receive status events through webhooks, and whether you need your own signing certificate set up before go-live. Teams that already run PostgreSQL and container platforms reach a test environment faster than teams starting from scratch. Neither vendor's supplied documentation gives a fixed integration duration, so ask a partner for a written timeline tied to a named list of templates and integration points, and ask what testing is included before production.
What does our team need to provide for the integration?
Plan for four inputs. First, an environment you control, such as a cloud account, data center or Kubernetes cluster, plus a PostgreSQL database, since Documenso uses PostgreSQL and DocuSeal can use PostgreSQL or MySQL instead of its SQLite default. Second, engineers who know your application's authentication, user model and document storage. Third, a decision on signing certificates, including whether you will use a self-signed .p12 certificate or a key service such as Google Cloud KMS, which Documenso's SIGNING.md documents. Fourth, a mail path for signer invitations, because signers must receive links reliably. Ask the partner to list these dependencies in the scope document so that gaps appear before development starts.
Can our in-house engineers build embedded signing alone?
Often yes, if your team has experience with webhooks, document storage and access control, and if the project has a clear owner. The hard parts are rarely the API calls themselves. They include keeping signer links secure, designing audit records you can produce later, handling declined or expired envelopes, and operating the platform after launch with upgrades and backups. Teams that build alone should plan for ongoing maintenance of the signing service, not only the first release. A partner can cover the parts your team lacks, such as security review, hardening, documentation and upgrade support, under a fixed scope. Decide which parts you keep in-house before you request a quote.
How does AGPL affect a closed-source SaaS that embeds signing?
Documenso is licensed under AGPL-3.0, and DocuSeal is distributed under AGPLv3 with Section 7(b) additional terms. Under AGPL, if you modify the signing software and let users interact with it over a network, you generally must offer the corresponding source of your modified version to those users. Running an unmodified copy internally, or calling it through a separate API with no modifications to the code, raises different obligations. Documenso's README says the code stays open source to read, audit, run and fork. Have counsel review your exact deployment, especially if you change templates in code, patch the signing flow or bundle the service into your product. Confirm the Section 7(b) terms in DocuSeal's repository with counsel as well.
Which signing edition do we need to embed signing?
The answer depends on whether you need the API, embedded signing and white-labeling. On Documenso's pricing page, the Teams plan adds API access and embedded signing, and the Platform plan adds white-labeled embedded signing. On DocuSeal, the free on-premises edition has no embedded signing, while On-Premises Pro adds white-label and embedded signing. Note that a plan's listed features can change, so confirm the exact edition, licensing terms and self-hosting options with the vendor in writing. For self-hosted use, ask whether the chosen edition's license covers your planned distribution model, since it determines whether your customers receive the signing service through your product.
How do per-completion fees change as signing volume grows?
On DocuSeal, API and embedding usage is billed at $0.20 per completion on its cloud and On-Premises Pro plans, and the cloud version requires at least one Pro seat for that usage. Total fees therefore rise in a straight line with completed signatures. For a self-hosted edition, the per-completion charge is the main variable cost, while infrastructure and staff time stay largely fixed. Model your expected completions per month against the pricing page, then compare that with a flat per-user or enterprise license. Ask vendors and partners to state which usage counts as a completion, how declined or expired envelopes are billed, and whether any volume tier applies.
What to ask an implementation partner before you commit
Start with the edition. Ask the partner to state in writing which edition covers embedded signing and white-labeling for your use, and to confirm that the price and license terms quoted match that edition. Documenso's Teams plan adds API access and embedded signing, and Platform adds white-labeled embedded signing. DocuSeal's free on-premises edition has no embedded signing, while On-Premises Pro adds white-label and embedded signing. Ask the partner to show where each feature appears in the vendor's current license or pricing terms, and ask who verifies that against the version you deploy, since vendor pages change.
Next, ask how the AGPL position is documented for your architecture. Both Documenso and DocuSeal are AGPL-licensed, so ask whether the partner will map which components you modify, which you only call over an API, and which you distribute to customers or users over a network. Ask for a written memo or architecture note that your counsel can review, and for the exact source-availability steps the partner will take for any modified code. DocuSeal's license includes Section 7(b) additional terms, so ask the partner to explain how those terms are applied in your build. Finally, settle the operational questions in the scope document: how signing certificates are issued and rotated (including the self-signed .p12 option or a cloud key service, and who holds the keys), how webhooks are tested and retried, how tenant isolation is enforced between your customers, how per-completion charges are metered and reconciled, and what support looks like after go-live. Because engagements are fixed-scope, ask for all of these as named deliverables with acceptance criteria, not as general assurances.
How DeployOpen scopes and supports an embedded signing build
The sequence turns an embedding idea into a written scope, a tested signing integration running in your environment, and a handover your team and auditors can follow. DeployOpen implements and hardens the platform, while your legal, compliance and security owners make the decisions only they can make.
Confirm the signing use cases and edition
DeployOpen reviews which documents your product must sign, the signer roles, the volume and whether you need white-labeled or embedded signing. From those answers we compare Documenso and DocuSeal editions against the features each use case needs, including API access, embedded signing, white-label and SSO. The output is a written edition recommendation that your product and procurement owners can approve before any build work starts.
Review licensing with your legal team
Both Documenso and DocuSeal are licensed under AGPL-3.0, so DeployOpen documents what the license means for your product if you modify the signing code, host it for users or distribute it. We prepare a licensing summary for your counsel to review, and we flag where commercial licenses or edition terms may apply. DeployOpen does not provide legal opinions, so the output is a question list and a documented position that your counsel signs off on.
Design the architecture and signing certificates
We design the deployment in your cloud account, data center or private network, covering the database, storage, email delivery for signer invitations, network paths between your app and the signing service, and the signing certificate approach. Documented options include a self-signed certificate generated with OpenSSL or signing through a managed key service such as Google Cloud KMS, and your security team chooses the approach. The output is an architecture diagram and a certificate decision record.
Build the API, webhook and embedded integration
DeployOpen implements the connection between your application and the signing platform through its API, webhooks and embedded signing components, including user provisioning, template mapping, signer identity fields and status callbacks back into your data model. Customizations stay in a version-controlled repository with documented changes. The check that closes this step is a working integration in a non-production environment that creates, sends, completes and records a document end to end.
Harden the deployment and test the controls
We apply hardening to the platform and its surroundings, including access control for administrators, encryption in transit for signer links, secrets handling, logging for audit controls and backup and restore procedures. Security testing of the application, its APIs and its signing flow can be included in scope. The output is a test report listing findings, their fixes and any items your team must accept or remediate.
Prepare compliance evidence for your assessments
DeployOpen collects the configuration records, access rules, audit log samples, retention settings and test results that your compliance and assessment teams will request. We map these artifacts to the controls your framework expects, but the mapping is evidence preparation, not an attestation. Independent auditors and certification bodies decide whether the controls meet their requirements, and the output is an evidence pack your compliance lead can hand to them.
Hand over runbooks and train operators
We deliver documentation covering installation, configuration, upgrade steps, backup and restore, incident handling and the integration contract with your product, then walk your platform and support teams through them. Knowledge transfer is complete when your team can perform a test upgrade and a restore from backup without DeployOpen present. The handover record lists who was trained and which runbooks they signed off.
Agree ongoing support and upgrades
After go-live, you choose between handling upgrades internally and a retainer that covers support, scheduled upgrades to new releases, continuous testing and updated evidence. Retainers are agreed in writing, with their scope and response expectations defined before signing. The output is a support agreement that names the owner on each side for patches, releases and incidents.
