--- title: "PandaDoc API Guide: What It Covers, When to Use It, and What a Build Involves" description: "A decision-level guide to the PandaDoc API: document creation from templates, variables and fields, pricing table data, status webhooks, when an API build beats Zapier or native integrations, and what a real proposal-generation build involves." canonical: https://pureproposals.com/pandadoc-api-guide/ published: 2026-10-26 image: https://pureproposals.com/images/blog/pandadoc-api-guide/0.png site: Pure Proposals type: article --- # PandaDoc API Guide: What It Covers, When to Use It, and What a Build Involves > A decision-level guide to the PandaDoc API: document creation from templates, variables and fields, pricing table data, status webhooks, when an API build beats Zapier or native integrations, and what a real proposal-generation build involves. _Source of truth: https://pureproposals.com/pandadoc-api-guide/_ The PandaDoc API is a REST API that lets your own systems create documents from templates, fill variables and fields, populate pricing tables with live data, send for signature, and listen for status changes over webhooks. You should reach for it when document volume, custom pricing logic, or a system of record outside your CRM makes the native integrations and Zapier too blunt; for a standard CRM-to-proposal flow, the native integration is almost always the better first move. This guide covers what the API actually does, where it beats the no-code options, what it costs to run in practice, and what a typical proposal-generation build looks like. It is written for the person deciding whether to commission a build, not the developer writing it; the developer should go straight to [developers.pandadoc.com](https://developers.pandadoc.com). ## Key takeaways - The API's core loop is create from template, fill tokens and fields, populate the pricing table, send, then react to status webhooks; that loop covers most proposal automation a business needs - Use the native CRM integration first, Zapier for light cross-tool glue, and the API when volume, pricing logic, or an off-CRM system of record demands it - Sandbox API keys are available on any PandaDoc plan, including trials, at 10 requests per minute; production keys run per-endpoint limits such as 500 creates from template per minute - An API build needs an owner, not just a developer: templates, catalog pricing, and CRM fields keep changing after launch, and unowned integrations rot - A typical proposal-generation build is measured in weeks, and most of the work is mapping your pricing and data, not writing code ## What the PandaDoc API actually covers Four capabilities carry nearly every business use case. **Document creation from templates.** The create-document endpoint takes a template ID, a recipient list with roles, and the data to merge. Your system decides when a proposal should exist (a deal hits a stage, an order lands, a form is submitted) and the API produces it from the approved template in seconds. This is the same template your team maintains in the PandaDoc editor, so design stays with the people who own the brand and data flow stays with the system. **Variables and fields.** Tokens (variables) fill in the per-deal details that someone would otherwise retype: client name, scope summary, dates, totals. Fields are the interactive layer the recipient touches: signatures, text boxes, checkboxes, dropdowns, and the API can pre-fill those too. The distinction matters when you design the template: variables for everything your systems already know, fields only for what the client must provide. Across 105 sales calls we ran, 82 of 129 companies named manual creation time as a top pain, and retyping known data into documents is exactly the work this kills. **Pricing table data.** The API populates pricing tables with rows, quantities, taxes, and fees from your own numbers. This is the capability that separates the API from a mail-merge: when pricing lives in an ERP, a billing platform, or a spreadsheet model too complex for CRM fields, the API is how each proposal gets current, calculated prices instead of whatever a rep remembered. Teams that fear a mispriced quote more than a slow one usually end up here. **Status webhooks.** PandaDoc calls your endpoint when a document is sent, viewed, completed, or declined, with HMAC-signed payloads so you can verify authenticity. That closes the loop: the signed proposal updates the deal, triggers provisioning or invoicing, and nobody checks a dashboard to find out. Webhooks are also the piece most no-code setups fake with polling, which is slower and noisier. Beyond those four, the API also reaches templates and the content library, the product catalog and quotes (the CPQ layer), document attachments, reminders, and audit trails, plus embedded editor and signing sessions if you want PandaDoc inside your own app. OAuth 2.0 is there for multi-account apps; a single company automating its own documents normally just uses an API key. ## API vs native integrations vs Zapier: the three-tier decision Our [Zapier integration guide](/pandadoc-zapier-integration-guide/) frames this as a three-tier decision, and the deciding question is what your system of record is. **Tier 1: the native integration.** If your deals live in HubSpot, Salesforce, Pipedrive, or Monday and a proposal should be created from a deal with its contact, company, and product data, the native integration already does that with no code to own. The [PandaDoc HubSpot integration](/pandadoc-integrations/hubspot/) covers token mapping, deal-stage triggers, and bidirectional status sync out of the box. Exhaust this tier before writing a line of code. **Tier 2: Zapier or Make.** Right when the trigger or data lives in a tool without a native integration and the flow is simple: a form tool kicks off an NDA, a project management tool triggers a renewal. Low volume, straightforward field mapping, no complex pricing. **Tier 3: the API.** Three signals push you here: - **Volume.** When documents are generated continuously rather than occasionally, per-task pricing on Zapier gets expensive and its retry behavior gets fragile. One client of ours runs roughly 700 documents a year through API generation because the documents are produced by their own platform, not by reps. At that shape of workload, direct calls with proper error handling beat a zap. - **Custom pricing logic.** If prices come from a calculation (tiered volume pricing, multi-year terms, tax rules, configurator output), the logic has to run somewhere real. Code calling the API can compute and populate exact pricing rows; a zap can only copy fields it can see. - **An off-CRM system of record.** When the truth about a deal lives in an ERP, a custom platform, a database, or a billing system, the API connects PandaDoc to it directly instead of forcing everything through a CRM that was never the source of truth. There is also a fourth, quieter signal: a person. In many teams someone manually re-keys data between systems every few days to keep documents accurate. We call that the human Zapier pattern, and it is the most reliable sign that an integration should exist and does not. If the data they copy comes from a system with its own database, the API is usually the fix. A hybrid is common and sensible: native integration for rep-sent proposals, API for machine-generated documents. The two coexist fine in one workspace. And if your CRM data itself is the complication, for example pricing held on HubSpot custom objects, there are patterns short of a full build; see our guide to [custom object merge fields](/pandadoc-hubspot-custom-object-merge-fields/). ## Build vs buy honesty: an API build needs an owner The code is the smaller half of an API project. The uncomfortable truth about every integration we have audited is that the build is an event and the integration is a process. Templates change: someone edits a token name and the merge silently stops filling it. Pricing changes: the catalog or the spreadsheet model gets new SKUs the integration does not know. The CRM changes: a property is renamed, a pipeline restructured. PandaDoc changes: webhook events and endpoints evolve. None of this is hypothetical; it is the ordinary drift of live systems, and it is why an integration with no owner degrades within months while everyone assumes it still works. So the build-vs-buy question is really an ownership question: - **Build in-house** when you have an engineering team that will own the integration as part of a product or platform, with monitoring, logging, and someone on the hook when document generation fails on a Friday. - **Commission the build** when you want the outcome without staffing it. Just be clear in the contract about who handles the drift: a build with no support arrangement is a countdown. - **Either way, line up ongoing ownership.** This is precisely what [ongoing PandaDoc support](/pandadoc-services/pandadoc-ongoing-support/) exists for: scheduled health checks on the integration, template and token governance so the merge never silently breaks, and a named owner when something fails. If nobody in the organisation can be named as the owner, that is not a reason to avoid automation. It is a reason to buy the ownership along with the build. ## Sandbox keys, workspaces, and limits Three practical facts shape how you start and how you scale. **Sandbox keys are free on any plan.** You can generate a sandbox API key from the Developer Dashboard on any PandaDoc plan, including a trial, and prove the whole flow end to end before committing. Sandbox keys are limited to 10 requests per minute, which is plenty for development and useless for production, by design. Production key availability depends on your PandaDoc plan and contract, so confirm that with PandaDoc before you schedule a build. **Production limits are per endpoint, per user.** At the time of writing, creating a document from a template allows 500 requests per minute, creating from an uploaded PDF 300, sending 400, reading document details 600, and list or status calls 2,000. Request bodies cap at 2 MB and PDF uploads at 50 MB. Those ceilings are far above most businesses' needs, but burst behavior matters: a batch job that fires hundreds of creations in one spike will hit 429 responses that a steady drip never would. Build backoff in from day one; our [429 rate limit guide](/pandadoc-api-rate-limit-429/) covers the retry patterns when you hit them anyway. **API keys are scoped to a workspace.** Each key belongs to one workspace, so documents, templates, and the catalog the API sees are that workspace's. If you run multiple brands or departments in separate workspaces, an integration that serves all of them needs a key per workspace and logic for routing between them. Plan this before the build, not after; our [workspaces guide](/pandadoc-workspaces-multi-brand-guide/) covers how multi-brand setups should be structured. ## What a typical API proposal-generation build involves A proposal-generation build, the most common API project we see, runs through five stages. The pattern holds whether the trigger is an e-commerce order, a field-service job, or an internal platform event. 1. **Data mapping.** Decide, field by field, where every piece of the proposal comes from: which system holds the client details, where pricing is calculated, what determines which template is used. This is the longest stage and the one that determines whether the project succeeds. It is analysis, not code. 2. **Template preparation.** Rebuild or adapt the PandaDoc template so every dynamic element is a token, a pricing table, or a content placeholder with a stable name. The template becomes an interface between your systems and the document, and like any interface it needs to stop changing casually once code depends on it. 3. **The generation service.** The actual code: receive the trigger, gather the data, compute pricing, call create-from-template, populate the pricing table, send or stage the document. Usually a small service or serverless function; days of work, not months, once stages 1 and 2 are honest. 4. **Webhook handling.** An endpoint that receives status events, verifies signatures, and updates your systems: deal stage on completion, an alert on decline, a nudge when a proposal sits unviewed. 5. **Error handling and monitoring.** The difference between a demo and a system. Retries with backoff for rate limits, alerts when generation fails, a log of every document created and why. This is also what the ongoing owner inherits. End to end, a focused build of this shape is typically two to six weeks depending on how many systems the data comes from and how complex the pricing logic is. If a developer quotes you two days, they have priced stage 3 and skipped the rest. Whichever tier you land on, the API is one layer of a working proposal system, not a substitute for one. Templates, pricing structure, CRM hygiene, and team process still decide whether proposals go out fast and correct; that bigger picture is what a [PandaDoc implementation](/pandadoc-implementation/) covers, and an API build slots into it as the automation layer, not the foundation. ## FAQ ### Do I need the PandaDoc API to connect PandaDoc to my CRM? No. HubSpot, Salesforce, Pipedrive, Monday, and others have native integrations that handle document creation, token filling, and status sync with no code. The API is for what the native integrations cannot express: machine-triggered generation at volume, computed pricing, or data living outside the CRM. ### What plan do I need to use the PandaDoc API? Sandbox keys are available on any plan, including trials, so you can prototype for free. Production API access depends on your plan and contract with PandaDoc, so confirm the current packaging with their team before committing to a build. ### Can the API fill in pricing automatically? Yes. The create-document call can populate pricing table rows with items, quantities, taxes, and fees supplied by your system, and the quotes endpoints cover the CPQ layer. This is the main reason teams with calculated or ERP-held pricing choose the API over no-code options. ### How long does a PandaDoc API integration take to build? A typical proposal-generation build is two to six weeks end to end. The code itself is a small share of that; mapping data sources, preparing templates, and building error handling and monitoring is where the time goes, and skipping those stages is why cheap builds fail in production. ### Who should maintain a PandaDoc API integration after launch? A named owner, either in-house engineering or a support partner. Templates, catalog pricing, and CRM fields keep changing after launch, and each change can silently break a merge. A monthly health check that sends one test document through the pipeline catches drift before a client sees it.