A sales contract has been signed, but the CRM still shows the deal as awaiting approval. The signed PDF sits in an inbox until someone downloads it, updates the deal, and attaches the file to the customer's record. That manual handoff delays the next step after signing.
eSign integration connects the signature request to the software that created the agreement. Employees send contracts from a supported application and receive signing updates there. Signeasy offers native connectors for business tools and an eSignature API for applications that need signing within their own interface.
This guide explains how those connections work, what developers build for a custom integration, how production usage is charged, and where Signeasy fits among eSignature providers.
What is eSign integration?
eSign integration brings eSignature functionality into business software. The connected application initiates a request or receives signing updates, and the completed agreement remains associated with the customer, employee, or transaction that generated it.
In HubSpot, for example, a sales representative can open a deal, prepare a contract using information in the CRM, and send it through Signeasy. The representative then follows the signature status from the same record. Without the connector, the team has to send the contract from a separate signing tool and upload the completed file manually.
Signeasy eSignature software supports direct signing and sending when employees do not need another business system to initiate the request. Integration becomes useful when another system needs to initiate the request or receive the result. A ready-made connector handles supported business applications; a custom eSignature API allows software to perform the transaction programmatically.
Three ways to integrate eSignatures into business software
Start the integration process with the application that holds the contract. Identify the action the business needs there: send a request, receive completion updates, or display the signing session. That determines the appropriate eSign integration method.
Native eSign integration with supported apps
A native connector is an eSignature integration built into software employees already use. With Signeasy for HubSpot, a sales representative selects a contract template, maps information from the CRM, and sends it for signature. The representative can track whether the recipient has opened or completed the request without managing a separate spreadsheet.
Document management introduces a related requirement: the completed agreement must return to a known library. Signeasy for SharePoint sends documents from a SharePoint library, tracks the request, and archives completed files in the connected library. Within Microsoft 365, Signeasy for Outlook supports signing actions on email attachments, while Signeasy for Teams brings document signing into the collaboration workspace.
Signeasy also supports Google Workspace, including Gmail, Docs, and Drive. The Google Sheets integration serves a different purpose: the sender chooses a saved template, maps spreadsheet columns to document fields, and sends requests using selected rows. This removes repetitive data entry from batch preparation without requiring a custom API.
Native eSign integration reduces custom software development for applications where Signeasy already maintains a supported connector. Their limits are practical: the actions exposed by a connector define what employees can do inside the host app. A proprietary customer portal that needs its own signer screen and database updates calls for an API instead.
Working in HubSpot or SharePoint already? Explore the Signeasy integrations directory, then see the signing steps in your existing application.
No-code eSign integration through automation services
A no-code eSignature integration transfers supported signing events between applications. A supported completed-document trigger, for example, can create a follow-up task in a project-management service. The automation works through the actions exposed by the two connectors; it does not add a signing interface to the destination application.
The person configuring the workflow authorizes each account and maps the agreement identifier to the correct destination record. Trigger selection matters too. An event for one recipient signing is different from confirmation that every required recipient has finished. Using the first event to close a multi-signer contract would update the record prematurely.
Automation services also have their own usage charges. A workflow that runs after every signer event can consume more tasks than one triggered by final agreement completion. For a product that needs signing inside its own interface, a custom API provides that control.
Custom eSign integration through an API
Custom eSign integration uses an API to connect the signing service directly to an application's code. After the host application authenticates, it sends the document and recipient details to the provider. The provider returns an identifier that the application stores against the original transaction. Subsequent status events and the completed PDF use that identifier to return to the right record.
The host application also determines where signing happens. Embedded signing displays the provider's user interface for signing within the website or product. Remote signing delivers a link to a hosted signing page, generally by email. For embedded signing, the host application authenticates the recipient and opens a signer-specific session.
The Signeasy Intermediate API plan includes embedded signing and sending. Our embedded signing guide explains the signer session, and the webhook documentation identifies the events an application uses to track completion.
Where businesses use eSign integration
An eSignature integration becomes valuable when a signature completes a task in another system. The destination for the signed document is therefore just as important as the place where the request begins.
The sales example works through a native connector when the CRM is supported. A custom onboarding portal uses an API to associate each signing request with its own customer ID. Recruiting teams working in Teamtailor can also use Signeasy for Teamtailor to prepare hiring documents from candidate information without developing that connection themselves.
How to implement eSign API integration in your application
A reliable eSign integration follows the document from its original record to the final signed file, including each API event that updates the transaction. The example follows an HR onboarding process: a portal generates an offer letter, sends it to a candidate, and stores the accepted offer in that candidate's profile.
Step 1. Select the API plan and create a developer application
Begin with the HR portal's required signing experience. Embedded signing needs a plan that includes an in-app recipient session. Hosted signing needs a signature request and delivery mechanism. Examine the provider's sandbox environment, supported methods, API documentation, and production allowance before creating the application.
Signeasy's getting-started guide explains how to configure a developer application and prepare the environment for testing.
Step 2. Authenticate the application
Register the application with the eSignature provider, then obtain the supported OAuth token. The HR portal's backend stores the credentials and includes the token in authorized API requests. Browser code should never expose client secrets.
Restrict the application's permissions to the operations it performs to reduce the risk of unauthorized access. An HR portal should also permit only authorized recruiters to issue offer letters. Signeasy's API reference documents the authentication and request endpoints.
Step 3. Prepare the offer letter and assign signing fields
Upload the approved offer-letter PDF or populate a reusable template with the candidate's information. Add the candidate's signature field and assign any required company signer. Set the signing order before dispatch if the company representative signs first.
Store the candidate ID alongside the document identifier. The HR portal will use that connection when the signature request is completed.
Step 4. Create the signature request
Send the document reference and signer assignments through the API. The signing service returns a request or envelope ID. Save that ID with the candidate record so future status events cannot be confused with another offer.
A single envelope can contain related files, such as an offer letter and confidentiality agreement. The application should still track the completion state for the whole request when multiple signatures are required.
Step 5. Present the signing session
For embedded signing, the HR portal requests a signer-specific session URL and displays it to the authenticated candidate. The portal controls access to the session and the screen displayed after completion. With remote signing, the candidate opens the provider's hosted page from the invitation.
The mobile user experience needs the same completion path. Test the document layout and fields on a phone, including the return to the candidate's account after signing.
Step 6. Process status events through webhooks
A webhook sends a status event to the HR portal's callback URL. Signeasy's rs.signed event records an individual signature; rs.completed indicates that every required signer has finished. The portal should update an offer to Accepted only after confirming the completed request.
Signeasy includes a verification token in webhook metadata. The receiver checks that token, handles duplicate deliveries, and processes events safely when they arrive out of order. These checks protect data integrity by preventing an incomplete offer from being marked as final.
Step 7. Save the completed PDF and audit information
After final completion, the application downloads the signed PDF and available signing evidence. The HR portal stores those records in the candidate profile under the employer's retention policy. The completed status should link back to the document that was actually signed.
Before going live, run the same transaction with a declined offer, an expired link, and a failed webhook delivery. Those outcomes need separate statuses; none represents an accepted agreement.
See this HR workflow in Signeasy, from an authenticated signature request to the completed document saved against the right record.
What developers should test before launching an eSign integration
A successful sandbox test establishes that the eSign integration can reach the API. Production readiness also depends on secure sessions, complete event handling, and accurate document access. Test these requirements using representative document types and redacted data.
- API credentials: Keep OAuth secrets on the backend. Limit permissions and revoke credentials when accounts are disconnected.
- Recipient access: Confirm that embedded signing URLs are issued to the intended authenticated user. Test expired sessions and access from another device.
- Webhook delivery: Validate the provider token, accept retries safely, and process duplicate or out-of-order events without generating multiple records.
- Request failures: Handle rate limits, slow response times, and temporary errors without issuing duplicate signature requests after uncertain responses.
- Unfinished documents: Keep declined, voided, and expired requests separate from completed agreements, especially when several people need to sign.
- Document retention: Confirm the destination for signed PDFs and audit records, the employees permitted to retrieve them, and the retention period.
- Legal requirements: Record signer intent and consent as required by applicable law. US workflows should account for the ESIGN Act and relevant state electronic-signature law, including UETA where adopted. Cross-border agreements can involve eIDAS.
An API supplies the technical signing process. The document, signer consent, authentication method, and governing law determine whether that process meets the legal requirements for the transaction.
How much does eSign integration cost?
The cost of eSign integration depends first on whether the business uses a native connector, automation platform, or custom API. Native add-ons use the applicable eSignature subscription and any connector charges. No-code platforms bill according to their own task or subscription rules. A custom API has separate production entitlements, usage allowances, and support terms.
Production signing charges should not be confused with the cost of ordinary API calls. Providers generally distinguish between requests that create or send an agreement and calls that retrieve its status. Their production plans also count different events.
Consider an application that sends 100 individual envelopes during a month. Recipients fully sign 70; the remaining 30 expire or stay unfinished. A sent-envelope meter counts 100 at dispatch. A completed-envelope meter counts 70 after signature completion. That difference affects usage, but subscription price and the included allowance still determine the total bill.
Signeasy deducts paid API credits when all required recipients finish an envelope. The Intermediate API plan costs $125/month, billed $1,499 annually, and includes 1,000 completed envelopes per subscription year. The Advanced API plan costs $250/month, billed $2,999 annually, and includes 2,000 completed envelopes, along with embedded template creation and additional authentication options. Signeasy also offers a developer sandbox for evaluation. Paid annual allowances apply to the subscription period; unused credits do not roll forward.
Which eSign API providers should businesses compare?
Signeasy is a starting point for growing businesses whose applications already prepare agreements. The Signeasy Intermediate API plan includes embedded signing and webhook updates, with paid credits deducted for completed requests. The alternatives below differ in document creation, feature access, and the event their subscriptions count.
Signeasy's completion-based allowance is particularly relevant where a meaningful share of requests never reaches final signature. Docusign offers a broader suite of agreement APIs and paid developer tiers, while its Starter price should not be treated as proof that every embedded function is included. Adobe's customer-facing embedded deployment has a partnership requirement. Dropbox Sign supports embedded signing on its Standard API plan, and PandaDoc brings document-generation functionality useful for proposal-heavy applications. Zoho's prepaid API-only offer avoids a recurring subscription, although its credits are consumed when requests are sent.
The provider decision should follow the application requirements already established: whether a document is prepared elsewhere, where the recipient signs, and when the signed record returns. The best eSignature APIs comparison covers the wider provider set. For plan details, see the Docusign API pricing guide and PandaDoc API guide.
Already create your contracts in another system? Review the embedded features and billable events with Signeasy using your expected request volume.
How Signeasy supports eSign integration for growing businesses
Signeasy offers native connectors for supported business applications and a separate API for software teams building their own signing experience. A sales representative working in HubSpot uses the connector already available in the CRM. A software business embedding a recipient session in its customer portal uses the eSignature API. Both keep signing tied to the original business process.
Bring signature requests into the apps employees already use
Signeasy's native integrations keep document preparation close to the business record. A HubSpot user sends an agreement from a deal and follows its status without compiling a separate tracker. A SharePoint user sends a contract from a document library and retrieves the completed agreement from the connected archive. This also gives employees a defined location for the signed file when the original sender is unavailable.
Embed signatures in a customer portal through Signeasy API
The API addresses software products where the recipient should stay in the host application. Signeasy Intermediate supports a signer-specific embedded session, embedded sending for authorized application users, reusable templates, and completion webhooks. After every required signature is collected, the application retrieves the signed file and stores the result against its own transaction ID.
The Advanced API plan adds embedded template creation, useful for products where users prepare recurring documents without leaving the host interface. Signeasy's paid completion-based usage also distinguishes a request that was sent from a request that has been fully signed. This gives software teams a consistent way to compare their completion rate with the plan's annual allowance.
See the Signeasy API process from the first signing request to the final webhook and signed PDF. The demo can follow your application's document flow.
See the API at work in Signeasy customer applications
ZenEquity integrated Signeasy into its employee equity platform. Employees open grant letters through the platform and sign in a pop-up; the accepted grant is then recorded in the product. ZenEquity's engineering lead reported completing the integration in approximately one month, with implementation support from Signeasy.
Education teams also need the signed file returned to the original student record. Moreland University connected Signeasy to its learning management system so enrollment agreements return to candidate profiles after signing. Moreland reports a 50–70% reduction in document turnaround time and processes onboarding agreements for more than 200 candidates each month. These figures reflect the organizations' published experiences, not guaranteed results for every deployment.
A business replacing another API also needs to preserve contracts that are already in progress. The new integration requires mapped templates and recipients, updated authentication, and a plan for previously completed documents. Signeasy offers migration assistance and competitor contract buyout options for qualifying customers, with the scope and commercial terms discussed before the migration begins.
