Every e-signature integration guide eventually admits that the connector does less than the marketing implies. This one can skip the detective work, because HubSpot has already written the admission down. In the knowledge base article for its own Docusign integration, one sentence settles the question that the rest of the category argues about: this integration is not a data sync app that syncs full record details to Docusign.
That is refreshingly honest, and it is also easy to under-read. It sounds like a caveat about completeness, as though most of the record moves and some of it does not. What it actually describes is a one-way fill. HubSpot property values populate fields in an envelope, the envelope goes out, and what comes back is the envelope's own paperwork: its status, its recipients, its sender, and when it was created and last updated. Nothing a signer enters into the document lands on a HubSpot property. Ever.
For a large number of teams that is completely fine, and this guide is not an argument against installing it. It is an argument for knowing exactly which half you are getting, because the second half is real, it exists, and it is sold separately in a different product on a different plan line. This guide covers what moves in each direction, the three gates that decide what you can configure, the licensing meter that decides how many envelopes your automation can actually send, and the point at which a build is the honest answer. It sits alongside the broader guide to HubSpot integrations, focused on the stretch between the deal and the signature.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Why the E-Signature Category Exists at All
Before looking at Docusign, it is worth understanding why so many HubSpot portals reach for a third-party signature tool when HubSpot ships e-signatures of its own. The answer is not that the native feature is bad. It is that the native feature is metered, and metered in a way that surprises people.
Three details in that allowance do most of the damage. It requires an assigned Revenue Hub seat, so the feature is not available simply because you pay HubSpot. The count is consumed at publish rather than at signature, so quotes that are sent and ignored still cost you. And if a quote expires or is recalled, resending it counts again, which means a slow negotiation burns the allowance twice for one deal.
None of that is unreasonable pricing for a CRM that is not primarily a signature vendor. It does explain the shape of the market. Teams whose paperwork volume is modest stay native. Teams whose paperwork is the business go and get a signature platform, and then need it to talk to the CRM.
Does HubSpot Integrate With Docusign?
Yes, and the entry price is unusually low. HubSpot lists the Docusign app as available with all products and plans, including free ones, which is a meaningfully wider door than most integrations in this category offer. The PandaDoc equivalent, covered in the HubSpot PandaDoc integration guide, requires a PandaDoc Business plan before the CRM connection works at all.
The requirements sit on the Docusign side instead. You need a paid Docusign plan, and you must be a Docusign Admin in your Docusign account to install it. To install on the HubSpot side you need Super Admin status or App Marketplace permissions.
Once connected, the app does three things. It lets you create and send an envelope from a contact, company or deal record. It populates fields in that envelope from mapped HubSpot properties, which appear on the Docusign side in Custom Fields prefixed with HS. And it shows you, against the record, which envelopes have been sent, their status, their recipients, their sender, and their create and last updated dates.
What the Docusign HubSpot Integration Actually Does
The cleanest way to understand this connector is to lay the two directions side by side and notice that they are not the same kind of thing at all. One direction carries data. The other carries news about data.
| HubSpot to Docusign | Docusign to HubSpot | |
|---|---|---|
| What moves | Property values from contacts, companies and deals into mapped envelope fields | Envelope status, recipients, sender, and create and last updated dates |
| Granularity | Field level, per mapped property | Envelope level, no field values |
| What triggers it | A person creating an envelope from a record, or a workflow action | An envelope changing state |
| Objects covered | Contacts, companies, deals | The record the envelope was created from |
| Gate on configuration | Custom property mapping needs Docusign eSignature Business Pro or higher | None, because there is nothing to configure |
| Gate on automation | Workflows need a Hub Professional or Enterprise subscription | Not applicable |
Read the right-hand column on its own and the design intent becomes obvious. Docusign is telling HubSpot where the envelope got to. It is not telling HubSpot what the envelope says. Those are different products of thought, and the whole rest of this guide follows from the distinction.
The three gates
Almost every confused conversation about this integration traces back to one of three gates, and they sit in three different places, owned by two different vendors.
- The install gate is on the Docusign side. A paid Docusign plan and Docusign Admin rights. Nothing about your HubSpot tier stops you here.
- The configuration gate is on the Docusign plan line. HubSpot states that custom property mapping is only available for Docusign eSignature Business Pro or higher plans. Below that tier you get the integration but not the ability to map your own fields into it, which for most real templates is the part you came for.
- The automation gate is on the HubSpot plan line. Sending envelopes from a workflow requires a Marketing Hub, Sales Hub, Data Hub or Service Hub Professional or Enterprise subscription. On a Starter or free portal, the integration is a manual tool.
A team on a free HubSpot portal and a basic Docusign plan can install this app and find that they can neither map their own fields nor send automatically. Nothing failed. They passed the only gate that was checked at install time.
How to Connect Docusign to HubSpot
1. Confirm the Docusign plan tier before anything else
Custom property mapping requires Docusign eSignature Business Pro or higher. If your templates need anything beyond the handful of standard recipient details, checking this first saves you from discovering the constraint after you have already built the templates.
2. Install from the HubSpot App Marketplace as a Super Admin
Marketplace icon, then HubSpot Marketplace, search for the Docusign app, install, and authorise with your Docusign credentials. You need Super Admin status or App Marketplace permissions on the HubSpot side and Docusign Admin rights on theirs.
3. Plan for the fact that every user connects separately
HubSpot states that Docusign is a user-level app, and that each HubSpot user must connect their Docusign user. Installing it once as an admin does not switch it on for the team. Build this into onboarding, and more importantly into offboarding, because a connection that belongs to a person behaves differently from one that belongs to a portal.
4. Build the property mappings per object
Settings, Connected Apps, Docusign, Settings tab, Property Mappings, then choose the object tab. Map HubSpot properties to the envelope fields that should carry them. Your mapped properties surface in Docusign under Custom Fields with an HS prefix, which is the quickest way to confirm a mapping actually took.
5. Give every custom Docusign field a unique tooltip and a text field type
This is documented and it is the single most common reason a mapping silently does nothing. To map a custom Docusign field, it should have a unique tooltip and a text field type. Duplicate tooltips across a template are the usual culprit, and they fail quietly rather than loudly.
6. Add the HMAC key if you are handling anything sensitive
Under Settings, Connected Apps, Docusign, the Actions menu exposes HMAC settings. If contracts in your portal carry anything you would not want spoofed, configure this at setup rather than adding it during a security review later.
7. Test the workflow action against a messy deal, not a clean one
The workflow limits below are all about recipients, and they only show up on records that look like real ones. Test with a deal that has three associated contacts, a deal that has none, and a contact whose email address appears twice in your portal.
Where the Native Docusign HubSpot Integration Stops
Everything here is documented behaviour rather than a defect, which is exactly why no amount of configuration gets around it.
The limits that decide whether the native app is enough
No field values come back. The return path carries envelope status, recipients, sender and timestamps. If a signer corrects a billing entity, adds a PO number, chooses a term length or amends an address inside the document, that value stays in Docusign. Your CRM keeps whatever it had before, and nothing flags the difference.
Custom objects and quotes are out of scope. The documented objects are contacts, companies and deals. If the thing your agreement describes is modelled as a custom object, the workaround is a workflow that copies those values onto the deal so an envelope can read them, which leaves you maintaining a shadow set of deal properties whose only purpose is to be legible to a signature tool.
It is a user-level app. Each HubSpot user must connect their own Docusign user. There is no portal-level service connection, so the integration is really a set of per-person connections that happen to share a configuration. Departures, seat changes and Docusign licence reassignments all become integration events.
Only fields mapped to the originating record populate automatically. HubSpot states that only fields mapped to properties on the contact or deal record used to create the envelope are automatically populated. Company data is the common casualty. An envelope raised from a contact does not automatically carry the company's legal entity name or registered address unless you go and apply the suggestions.
The workflow action is constrained by recipient arithmetic. In a contact-based workflow the selected template can only set the enrolled contact as a recipient, and if it has more than one recipient to populate the action will fail to execute. In a deal-based workflow the number of recipients on the template must match or be less than the number of associated contacts on the enrolled deal. In a company-based workflow HubSpot will not auto-set the recipients at all. Any template with a countersigner, a legal reviewer or a second signatory runs straight into this.
Duplicate email recipients are skipped. During auto-population, a repeated email address is passed over. In portals where one person is both the billing contact and the signatory, this produces envelopes that are missing a recipient for a reason nobody can see from the record.
Custom mapping is gated on the Docusign plan. Custom property mapping requires Docusign eSignature Business Pro or higher, so the cost of mapping your own data is a Docusign upgrade rather than a HubSpot one.
Nothing reconciles. The structural one, and it is the same finding as every other event-driven connector. There is no pass that ever compares the executed agreement against the CRM record and reports the difference, because the integration has no concept of the agreement's contents to compare with.
An envelope status tells you the agreement arrived somewhere. It tells you nothing about what the agreement says. Only one of those is what the rest of your business runs on.
The Write-Back Path Exists, and It Is a Different Product
Here is the part that most comparisons miss. Docusign can write into HubSpot. It just does not do it from the HubSpot marketplace app.
Docusign's Maestro workflow builder provides a Writeback to HubSpot step, which updates HubSpot records with data from a Docusign workflow, and a Read from HubSpot step, which pulls HubSpot record data into the workflow. Administrators link workflow fields to HubSpot fields inside the writeback step. That is a genuine return path with field-level granularity, and it is exactly the thing the marketplace app does not have.
The catch is where it lives. Docusign's plan allowances page lists Workflow Builder across the IAM Standard, Professional and Enterprise plans, along with IAM for Sales and IAM for CX. IAM is Docusign's Intelligent Agreement Management product line, which is a different and more expensive commitment than eSignature. So the answer to "can Docusign update my HubSpot deal when the contract is signed" is yes, on a different plan family, configured on the Docusign side, in a tool your HubSpot admin does not own.
What It Costs on Both Sides
The HubSpot side is the simple half. The app installs free on all products and plans. Workflow-driven sending needs a Hub Professional or Enterprise subscription, which most teams considering this already have for other reasons.
The Docusign side is where the real decisions are. Docusign's own pricing lists IAM Starter at 45 dollars per user per month, IAM Standard at 50, and IAM Professional at 80, all on annual billing, with Standard and Professional carrying a three-user minimum, and IAM Enterprise priced by quote. Custom property mapping requires eSignature Business Pro or higher, and Workflow Builder requires IAM Standard or above.
Then there is the meter almost nobody checks before scoping a project, and it is the most consequential number on this page.
Sit with the asymmetry, because it is the opposite of what everyone assumes. A rep who opens Docusign and clicks send is unlimited. The identical envelope, sent by your integration, is drawn from a pool of roughly eight per user per month. Automating a process does not just fail to save money here, it moves the send into a scarcer bucket.
The arithmetic gets uncomfortable quickly. A ten-seat account has 1,000 automation sends a year to share. A team sending 100 contracts a month through an automated flow needs 1,200. They are over the allowance in month ten, having done nothing wrong except automate something.
Docusign does soften this at the top of the range. Its plan allowances page states that on IAM Enterprise, IAM for Sales and IAM for CX, sends from a third-party integration do not count against that allowance, and that from 20 February 2026 those plans carry a separate pool of 200 sends per user per year for third-party integrations. Worth reading closely if you are scoping a build, because it draws a commercial distinction between an envelope sent by a partner integration and one sent by your own, which is a distinction that has nothing to do with engineering and everything to do with what you will be invoiced.
Docusign HubSpot Integration: Native vs iPaaS vs Custom
Three routes, and they stack rather than compete. If the middle term is unfamiliar, the guide to iPaaS covers the category properly.
Free to install on any HubSpot plan, quick to configure, and genuinely good at the job it describes. If your agreements are standard, your data lives on contacts and deals, and nobody downstream needs the values a signer entered, install it and build nothing. Start here.
Maestro's Writeback to HubSpot step is the vendor-supported version and comes with a move onto the IAM plan line. An iPaaS listening to Docusign Connect events is the tool-agnostic version and comes with a per-operation subscription that scales with volume. Both add fields. Neither adds reconciliation, and both still spend your automation sends allowance.
Built against the Docusign API and the HubSpot API directly, so custom object properties can be read without shadow fields, signed values write to the properties that own them, a failed write retries instead of vanishing, a reconciliation pass catches agreements whose results never landed, and an executed contract can continue into the ERP, the billing system or the provisioning queue rather than stopping at a status on a timeline.
When to Build a Custom HubSpot Docusign Integration
Almost nobody should start here. Install the app, run it for a quarter, and find out where it stops for your paperwork rather than for somebody else's. The skill is noticing the moment you have started working around the connector instead of with it.
Signs you have outgrown the native app
Somebody reads signed contracts and types the values into HubSpot. This is the number one tell, and it is the direct consequence of a return path that carries no field values. It is also the version of the problem that looks like an admin task rather than an integration gap, which is why it survives for years.
Your agreements describe things held on custom objects. Subscriptions, policies, properties, vehicles, equipment schedules, service locations. Copying those onto the deal so an envelope can read them adds a new shadow property every time legal revises a clause.
The signed agreement is not the end of the process. An executed contract usually has to become an invoice, a subscription, a project or a provisioning task. A status on a timeline is where the native path finishes and nowhere near where the work finishes. The same seam appears from the finance side in the HubSpot QuickBooks integration guide and at a larger scale in the HubSpot ERP integration guide.
Templates need more than one recipient. Countersignatures, legal reviewers, dual signatories and internal approvers all collide with the workflow action's recipient arithmetic. If your standard agreement has two signers, the automated path is already narrower than your process.
A per-user connection is the wrong shape for how you send. Shared-inbox sending, a central contracts team, a service account that raises agreements on behalf of reps, or any high-volume automated flow all want a portal-level connection, which is not what a user-level app provides.
Approval logic has to sit between the deal and the send. Discount thresholds that need a manager, non-standard terms that need legal, values above a ceiling that need a countersignature. That logic needs one place to live, and splitting it across HubSpot workflows and Docusign workflows produces a maze nobody can safely edit two quarters later.
Rate limits to know before you scope a build
The interesting thing about this pairing is that the technical ceiling is not the one you hit first.
Now put those next to the licensing number and the real design constraint becomes clear. Three thousand API calls an hour is enough to send far more envelopes in a year than any IAM plan permits. The technical limit is generous and the commercial limit is tight, which means the thing to design around is not throughput at all, it is which sends are worth spending. That usually pushes the architecture the same way: listen to Connect events rather than poll, keep automated sending for the flows that genuinely need it, and let humans keep sending the one-offs from the web app where the allowance does not apply.
Ask anyone quoting for this work which limit they expect to bind first. If they talk about API throughput rather than automation sends, they have not shipped one of these.
What a Custom HubSpot Docusign Integration Costs
The honest comparison is not build versus free, because the native app stays installed either way and should. It is build versus the running cost of the alternative: the IAM upgrade that unlocks Maestro, the iPaaS subscription that scales with envelope volume, and the hours somebody spends every month reading executed agreements and typing their contents into the CRM.
A custom integration is a one-time build plus ongoing maintenance, priced by scope. Reading custom object properties into a template one way is a much smaller build than capturing signed values, writing them to the properties that own them, retrying failures and handing an executed agreement onward into billing. The cost teams underestimate is never the build. It is maintenance, because HubSpot properties change every time ops runs a cleanup and templates change every time legal revises a clause, and an unowned pipe between the two drifts until nobody trusts either side.
The cheapest moment to capture what a contract says is the moment it is signed. The most expensive is the renewal, when somebody opens the PDF to find out what was agreed because the CRM never knew.
That is why we productized it. StackTie builds the connection against the Docusign API and the HubSpot API directly for a fixed fee, then maintains it on a flat monthly retainer, so what the customer signed and what the CRM believes stay the same thing. The build fee and retainer are published on the pricing page rather than quoted per call.
Your CRM knows the contract was signed. Does it know what it says?
When signed values have to land on HubSpot properties, when the agreement describes something held on a custom object, when a second signatory breaks the workflow action, or when an executed contract has to continue into billing rather than stopping at a status, that is a build. StackTie builds custom HubSpot Docusign integrations for a fixed fee and maintains them on a flat monthly retainer, alongside the native app you already have. Live in 14 days or your money back. Book a free audit and we'll map exactly where your native option stops.
The Bottom Line
The Docusign HubSpot integration is a good piece of software that has been described badly by everyone except HubSpot. It installs free on any plan, it puts agreements in front of customers without anyone leaving the CRM, and it keeps the record honest about where each envelope got to. For a team whose contracts are standard and whose downstream systems do not need the contents, that is the whole job.
What it is not, in HubSpot's own words, is a data sync app. Values flow out into envelope fields and envelope metadata flows back, and the field-level return path lives in a different Docusign product on a different plan line. Add the three gates, the per-user connection model, the recipient arithmetic in the workflow action, and an automation sends allowance that rations exactly the sending you were trying to automate, and the picture is clear enough to plan against.
The line is easy to state. If you need to know that an agreement was signed, install the app. If you need to know what the agreement said, and you need the rest of your business to know it too, that is a different piece of software, and no amount of configuration turns one into the other.
