Most integration guides open by explaining why an app is disappointing. This one has to open the other way, because the HubSpot PandaDoc integration is genuinely good. PandaDoc builds it in house, HubSpot certifies it, and it is one of the most widely adopted apps in the marketplace. If you want a quote generated from a deal, sent, tracked, signed and paid without anyone leaving the CRM, it does that, and it does it well.
Then a rep gets on a call, knocks 8 percent off to close the quarter, edits the price inside the document, and the customer signs. The contract is correct. The deal in HubSpot still shows the old amount. Nobody notices until the forecast and the invoices disagree.
That gap is not a bug and it is not an oversight. It is written down in PandaDoc's own documentation, in a single sentence about field types that almost nobody reads before they build a process on top of the connector. This guide is about what the integration moves in each direction, the exact line where the return path stops, and how to tell whether you have a documents problem or a data problem. It sits alongside the broader guide to HubSpot integrations, focused on the stretch between the quote and the signature. If you are weighing the main alternative, the HubSpot Docusign integration guide covers the same seam from the other side, where the return path is narrower still.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
Does HubSpot Integrate With PandaDoc?
Yes, and the credentials are real. The app is built by PandaDoc rather than by a third-party sync vendor, it carries HubSpot Certified App status, and adoption is high.
Hold that number next to the rest of this guide, because it changes how you should read the criticism. When an app is rated 2.1, the useful question is what is broken. When an app is rated 4.4 across nearly three hundred ratings, the useful question is different: what does a well-built connector in this category structurally not do, no matter how well it is built?
The answer is that document tools and CRMs disagree about what a record is. HubSpot treats the deal as the durable truth. PandaDoc treats the document as the durable truth. For the ten minutes between generating a quote and getting it signed, that distinction does not matter. Afterwards it is the whole problem.
What the PandaDoc HubSpot Integration Actually Does
There are two connections, not one, and they are configured in different places. Most confusion about this integration traces back to someone having set up the first and expecting the behaviour of the second.
The CRM connection is the outbound half. It lets you create a document from a HubSpot contact, company or deal, and populate it with CRM data.
The HubSpot Automations connection is the return half. It is authorised separately, it is what writes results back into HubSpot when a document changes status, and PandaDoc's documentation is explicit that both connections must authenticate with the same account.
| HubSpot to PandaDoc | PandaDoc to HubSpot | |
|---|---|---|
| Configured in | The main CRM connection | A separate HubSpot Automations connection |
| Objects covered | Contacts, companies, deals | Deals, plus contact creation for new recipients |
| What moves | Variables, merge fields, and line items carrying price, quantity, discount, name, description and unit cost | Deal stage changes, PDF attachment, deal property updates, and line item add, remove or update |
| What triggers it | A person creating a document from a record | A document status change |
| Field types supported | Broad, with sensitive and highly sensitive tokens excluded | Text, Date, Dropdown, Checkbox and Radio Button only |
| Plan gate | PandaDoc Business or above | A paid Business add-on, or included with Enterprise |
Read that table left to right and the shape of the integration becomes obvious. The outbound direction is rich, because filling a document with data is what PandaDoc is for. The return direction is a set of four automation recipes bolted to a status change, because sending data back to a CRM is not what a document tool is for.
The four things PandaDoc can write back
PandaDoc documents exactly four HubSpot automations, and knowing the list is more useful than any general claim about two-way sync:
- Change the deal stage when a document status updates. This one accepts any document status except Draft as a trigger.
- Attach the PDF to the deal when the document status changes. Sent or Completed only.
- Update deal properties when the document status changes. Sent or Completed only.
- Update, add and remove line items when the document status changes. Sent or Completed only.
Three of the four fire on Sent or Completed and nothing else. That is worth sitting with, because the interesting states in a real sales process are the ones in between. Viewed and not signed. Signed by one party. Expired. Declined. Sent again after a revision. Those are the moments a pipeline actually turns on, and the write-back path does not address them.
How to Connect PandaDoc to HubSpot
1. Confirm the plan on the PandaDoc side first
The CRM integration requires a PandaDoc Business plan or higher, and the write-back automations are gated again on top of that. Checking this before you start saves discovering halfway through configuration that the half you actually came for is a separate line item.
2. Start from the correct side if you are in the EU
PandaDoc's help centre states that EU accounts must initiate the integration from PandaDoc rather than from HubSpot. Everyone else can start from either. It is a small detail that produces a confusing failure if you get it the wrong way round.
3. Authorise the main CRM connection
This is the connection that lets you generate documents from HubSpot records and pull deal, company and contact data into them. On its own it gives you the entire outbound half of the integration and nothing of the return half.
4. Authorise the HubSpot Automations connection separately
This is the step people miss. It is a distinct connection, and it must use the same account as the first one. Without it, documents will still be created and sent perfectly and absolutely nothing will come back to the deal.
5. Build the template with variables, not with typed values
Deal, company and contact data reaches the document through variables and merge fields. Anything a person types directly into a template is a value that will be wrong the next time the template is used. Note one documented quirk here: contact variables are not available when you create a document from a deal or a company, and the workaround PandaDoc suggests is to use template roles instead.
6. Map line items to a pricing table or quote builder block
HubSpot deal line items flow into PandaDoc pricing tables and quote builder blocks, carrying price, quantity, discount, name, description and unit cost. Set this up against a real deal with real products rather than a test record with one clean line.
7. Choose which of the four automations you need, then test a messy document
Turn on only the recipes you need and test with the sort of document your reps actually send: a negotiated discount, a line added during the call, a custom column, an empty optional field. That test tells you within an hour which of the limits below you are going to live with.
The Five Field Types That Sync Back
This is the most important paragraph in the guide, and in PandaDoc's documentation it is one sentence.
Number fields being excluded is the expensive one, because a quote is mostly numbers. Negotiated price, revised quantity, an agreed discount, a one-off setup fee waived to get the deal over the line. Every one of those is a number, every one of them can be edited inside the document, and none of them writes itself back to the deal.
So the sequence that plays out in a lot of HubSpot portals is this. The deal says 40,000 dollars. The rep negotiates to 36,800 in the document. The customer signs. HubSpot still says 40,000. The forecast is overstated, the commission calculation is wrong, and the invoice that finance raises from the CRM does not match the contract the customer holds. Nothing failed. No error was logged. The integration did exactly what it documents.
There are three smaller exclusions in the same family that catch people during configuration:
- Text values cannot populate number-only columns. Price, QTY, Discount, Tax and Fee columns reject text, which sounds obvious until a variable that usually contains a number arrives containing a dash or the word included.
- Subtotal columns auto-calculate, and that calculation prevents pulling a value into them.
- Fields containing only special symbols will not work, which is a genuinely odd edge that shows up with currency-only or placeholder values.
A document tool and a CRM can agree perfectly at the moment of signature and still disagree forever afterwards. The signature is an event. The deal amount is a state. Only one of them is what your forecast is built on.
Where the Native PandaDoc HubSpot Integration Stops
Every item here is documented behaviour rather than a defect, which is exactly why configuration does not get around them.
The limits that decide whether the native app is enough
Custom objects are out of scope. The integration covers contacts, companies and deals. Custom objects are unique to each portal, so a pre-built connector cannot anticipate their properties, and the standard workaround is a HubSpot workflow that copies those properties onto the associated deal before the document is generated. It works, and it leaves you maintaining a shadow set of deal fields whose only job is to be legible to a document tool.
Line item sync is all-or-nothing. PandaDoc states that if validation fails on any field during the line item sync, the entire automation fails. Not a partial update, not a warning against the offending line. One bad value and the deal is untouched while the document still reads as completed, which is the worst possible combination because it looks like success from both sides.
Hidden custom columns do not come back. Custom columns that were hidden during document creation will not sync back. Teams hide internal margin or cost columns from the customer-facing document as a matter of course, and those are frequently the columns ops most wants back on the deal.
Documents link to deals only. A document created from a company or a contact cannot be unlinked the way a deal-sourced one can. If your process generates paperwork against accounts rather than opportunities, such as renewals, NDAs or master agreements signed before any deal exists, that constraint shapes the whole design.
Sensitive and highly sensitive HubSpot data tokens are excluded. HubSpot's sensitive data classifications are unavailable to the integration, which matters for anyone in healthcare, financial services or insurance whose contracts have to state exactly the fields that classification exists to protect.
Taxes are not supported on the HubSpot side. Straightforwardly stated in the documentation, and a real constraint for anyone selling across jurisdictions where tax is not a rounding detail.
Nothing reconciles. The structural one, and it is the same finding as every other event-driven connector. The return path fires on a status change. If the automation was off, if validation failed, if the change happened during setup, or if the state you care about is not Sent or Completed, the two systems now disagree and there is no pass that ever notices. There is no declared system of record per field, so where both sides can write, the last writer wins by accident rather than by design.
What It Costs on Both Sides
Installing the app from the HubSpot App Marketplace costs nothing, which is where the free impression comes from, and it is only true of the installation.
On the PandaDoc side there are two separate gates. The CRM integration requires a Business plan or higher. The HubSpot automations, meaning the entire write-back direction, are documented as a paid add-on for the Business plan at 39 dollars per month per account, or 468 dollars per year per account, and are included with Enterprise.
PandaDoc 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.
Built by the vendor, certified by HubSpot, adopted by tens of thousands of teams. If your contracts state things that live on contacts, companies and deals, and nobody needs the negotiated number to reach the CRM automatically, this is the right answer and you should build nothing. Start here.
Listen to the PandaDoc webhook, write to the HubSpot properties the four native recipes do not touch, and you have bought yourself the fields without writing code. You are accepting a per-operation subscription that scales with document volume, and an automation layer that is still event-driven, so it adds fields without adding reconciliation.
Built against the PandaDoc API and the HubSpot API directly, so custom object properties can be read without shadow fields, a failed line item can retry instead of vanishing, every field has a declared owner, a reconciliation pass catches documents whose results never landed, and an executed contract can carry on into the ERP or the accounting system rather than stopping at a PDF on a deal.
When to Build a Custom HubSpot PandaDoc Integration
Almost nobody should start here. Install the native app, run it for a quarter, and find out where it stops for your paperwork rather than for someone else's. The skill is noticing the point at which you have started working around the connector instead of with it.
Signs you have outgrown the native app
Someone reconciles contracts against deals by hand. If a person opens signed documents and corrects deal amounts, that is the number field limitation showing up as a salary. It is also the version of the problem that silently corrupts forecasting for months before anyone traces it.
Your contracts state things that live on custom objects. Subscription terms, insured assets, properties, vehicles, service locations, equipment schedules. Copying those onto the deal so a document can read them is a workaround that grows a new field every time the business adds a clause.
The signed document is not the end of the process. A countersigned contract usually has to become an invoice, a subscription, a project or a provisioning task. Attaching a PDF to a deal is where the native path finishes, and it is nowhere near where the work finishes. This is the same seam described from the finance side in the HubSpot QuickBooks integration guide and the HubSpot ERP integration guide.
A failed sync needs to be seen by a human. All-or-nothing line item validation means failures are silent by construction. If a document can be completed while its deal quietly did not update, somebody needs to find out, and the native path has nowhere for that alert to go.
Approval rules need to sit between the quote and the send. Discount thresholds that require a manager, non-standard terms that require legal, deals above a value that require a countersignature. Conditional logic needs somewhere to run, and stringing it across two automation builders produces a maze nobody can safely edit six months later.
Nobody trusts the deal amount any more. The behavioural tell, and the most reliable one. When finance checks the signed PDF before believing the CRM, the integration has already failed even though every automation is still running exactly as documented.
Rate limits to know before you scope a build
The constraint here is not where people assume, and the endpoint that bottlenecks a real project is rarely the one that creates documents.
The design consequence is specific. A project that pulls three years of signed contracts into an accounting system is metered at 100 downloads per minute, not at the generous creation limit, and because the pool is per user rather than per key, that backfill has to yield to live traffic instead of competing with it. Ask anyone quoting for this work which endpoint they expect to bottleneck first. If the answer is document creation, they have not built one.
What a Custom HubSpot PandaDoc 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 automations add-on, the iPaaS subscription that scales with document volume, and the hours somebody spends every month reconciling signed contracts against deal amounts that were never going to update themselves.
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 bidirectional state with negotiated-value write-back, retry on validation failure, and a handoff into an ERP. 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 catch a wrong deal amount is the second the document is signed. The most expensive is the quarter-end review, after the forecast, the commission run and the invoice have all been built on it.
That is why we productized it. StackTie builds the connection against the PandaDoc 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 number. The build fee and retainer are published on the pricing page rather than quoted per call.
Signed at one number, forecast at another?
When contracts state things that live on custom objects, when negotiated prices have to reach the deal, when a failed line item sync needs to retry instead of vanishing, or when the executed document has to continue into your ERP, that is a build. StackTie builds custom HubSpot PandaDoc 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 HubSpot PandaDoc integration deserves its rating. It is built by the vendor, certified by HubSpot, installed by tens of thousands of teams, and it handles the job it was designed for, which is turning CRM data into a document a customer can sign, without anyone leaving HubSpot.
What it is not is a sync. The outbound direction is broad and the return direction is four recipes triggered by a document status change, bounded by five field types, gated behind a paid add-on, and scoped to standard objects. Number fields are outside that boundary, which means the one value most likely to change during a negotiation is the one value guaranteed not to come back.
For most teams that is fine, and the right move is to install it, use it, and correct the occasional amount by hand. It stops being fine at a predictable point: when your contracts describe things the CRM models as custom objects, when a signed document has to become an invoice rather than an attachment, or when the number in the contract and the number in the forecast have drifted far enough apart that somebody has started checking both. That is not a missing feature in a well-built app. It is the line between generating a document and owning the state that document changed, and only one of those is what a CRM is for.
