Adding e-signatures to a SaaS product
Adding e-signature to a SaaS product usually means your own customers need documents signed as part of using your product — an HR platform generating offer letters, a property management tool sending leases, a freelance marketplace getting service agreements signed — rather than you sending documents for your own internal business. That distinction (your customers' documents, not your own) changes some of the practical considerations compared to a simple internal integration.
Deciding where signing fits in your product's workflow
Before any API work, map out exactly where in your product a document gets created and needs a signature — generated from a template after a form submission, triggered by a status change, created manually by one of your users. This determines both your technical integration point and, just as importantly, what information you already have on hand to prefill into the document and the signer list.
Multi-tenant considerations
If your SaaS product serves many separate customers (tenants), each sending their own documents to their own signers, you need a clear mapping between your own tenant/customer records and the signature requests created on their behalf — typically by storing the resulting request ID against your own customer record the moment it's created. This is what lets you later show a specific customer only their own documents and requests, not anyone else's.
Choosing between your own API key and per-customer accounts
There are two broad approaches for a multi-tenant SaaS integration: use a single Esignapi account and API key for your whole product, creating requests on behalf of all your customers under that one account, or have each of your customers connect their own Esignapi account. The single-account approach is simpler to build and is the more common pattern for a feature embedded inside a broader product; giving each customer their own account makes more sense if they need independent billing, their own API key management, or direct access to Esignapi's own dashboard outside of your product.
Letting your customers manage requests without leaving your product
If your customers are the ones sending and tracking documents (rather than this happening automatically behind the scenes), embedding the document and request management panel inside your own interface — rather than redirecting them to a separate Esignapi dashboard — keeps the experience consistent with the rest of your product. See Embedded signing vs email signing: when to use each for exactly what that embed capability covers and what it doesn't.
Handling plan limits across many customers
API access requires at least a Pro plan on the account creating requests. If you're running a single shared account across many customers, make sure your own usage (document volume, request creation frequency) stays within whatever plan tier you're on, and plan for upgrading as your own customer base and their document volume grows — this is a cost and capacity planning question on your side, separate from anything your end customers see directly.
Surfacing signature status inside your own product
Rather than sending your customers to check status on a separate dashboard, use webhooks (or periodic polling, as a fallback) to keep your own product's UI in sync with what's actually happening — a document still pending, partially signed, or complete — so your customers get that information inside the product they're already using. See E-signature webhooks explained for the mechanics, including a limitation worth designing around.
What to tell your own customers about legal validity
If your product markets e-signature as a feature, it's worth being accurate with your own customers about what that means: the underlying signatures are legally valid under frameworks like the ESIGN Act of 2000 and eIDAS Regulation (EU) No 910/2014 for the large majority of commercial documents, but a small number of document categories are excluded or need extra steps — see Documents you can't sign electronically. If your product is used for any document type near those edges, it's worth flagging that distinction to your own customers rather than implying blanket coverage.
Error handling becomes your customers' problem too
If a document upload fails or a signer's email bounces, that failure now surfaces inside your own product rather than directly in Esignapi's dashboard, which means your own error handling and user-facing messaging need to account for it — a generic "something went wrong" isn't as useful to your customer as a message that tells them, for instance, that a specific signer's email address appears to be invalid.
Testing with real customer workflows in mind
Beyond the general integration testing described in Testing e-signature integrations safely, test your specific multi-tenant scenarios directly: two different simulated customers sending documents at the same time, confirming each only sees their own requests, and confirming webhook events get routed to update the correct tenant's data in your own system.
Deciding how much of the signing workflow to expose to customers
Not every customer needs the same level of control. Some SaaS products expose signing as a fully automated step the customer never directly interacts with (a document is generated and sent automatically as part of a larger workflow, with the customer only seeing a final status), while others give customers direct control over uploading documents, adding signers, and placing fields themselves. The right level of exposure depends on how central document signing is to your product's value — a product where e-signature is incidental to a larger workflow can hide most of the mechanics, while a product where document handling is a core feature benefits from giving customers more direct, visible control over it.
Supporting customers who want their own branding
If branding consistency inside the signing experience itself (not just your own product's surrounding UI) matters to your customers, check what white-labeling options are available on your account's plan before promising that level of customization to your own users — this is a separate consideration from simply embedding Esignapi's management panel inside your product's interface, which keeps your branding around the feature but doesn't by itself change what a signer sees once they reach the actual document.
Planning for customer churn and data retention
When a customer of your SaaS product stops using your service, think through what happens to the signature requests and signed documents associated with them — whether they remain accessible to you (for audit or support purposes), whether your customer expects continued access to their own historical documents after cancelling, and how that maps onto your own account structure if you're using a single shared Esignapi account across all your customers. This is a product and data-retention decision on your side, not something the underlying API enforces for you automatically.
Add e-signature to your product
Esignapi's API and embed capability let you build signing directly into your own SaaS product, whether that means creating requests behind the scenes or letting your customers manage them inside your own interface.
Frequently asked questions
Should I use one Esignapi account for all my customers, or one per customer?
A single account is simpler to build and manage, and is the more common approach for signing that's embedded as a feature within your product. Per-customer accounts make more sense if your customers need independent control over billing or their own direct dashboard access.
What plan do I need if I'm reselling e-signature as part of my own product?
API access requires at least the Pro plan on the account actually creating the requests, and your document volume needs across your customer base should inform which tier makes sense as that volume grows.
How do I keep one customer's documents separate from another's in a shared account?
Store the resulting signature request ID against your own customer record at creation time, and filter everything your product displays by that mapping rather than relying on Esignapi's dashboard to separate tenants for you.
Can my customers see Esignapi's branding when they use this feature inside my product?
That depends on your specific plan and setup — check your account's current white-labeling options if keeping your own branding fully consistent throughout the experience matters for your product.
What happens if my shared account hits its document limit because of customer volume?
Since usage across all your customers draws from the same account's plan allowance, monitor your aggregate volume and upgrade proactively rather than letting a limit interrupt service for customers who are depending on your product to work.