Document creation was treated as synchronous
The create endpoint is asynchronous. Code that assumes a document is ready the moment the call returns works in testing with one document and fails the first time the queue is busy.
REST API · Webhooks · Embedded Every connector has an edge.
Every connector has an edge.
This is the work on the other side of it.
Generating from a custom object. Producing two hundred documents on a schedule. Embedding signing inside your own product. None of these are settings — they are software, built against PandaDoc's REST API and webhooks, with authentication, rate limits, retries and error recovery that have to be designed rather than discovered. We build it, and we tell you what it costs to keep.
REST
4
Async
20s
Trusted by 500+ organizations — including revenue, sales operations and legal teams running document generation, quoting and e-signature on Salesforce and HubSpot with Twopir Consulting.
Technical Surface We Build On
- Salesforce Partner
- HubSpot Partner
- REST API
- Webhooks
- JavaScript SDK
- Platform Events
- Custom Objects
- Bulk Generation
The six things that break a PandaDoc API integration
Every one of these is cheap to design for and expensive to retrofit. We have been called in to fix all six.
Rate limits were discovered in production
PandaDoc enforces per-endpoint limits and returns 429 when you exceed them. An integration with no queueing or back-off hits that ceiling during exactly the quarter-end push it was built for.
Webhooks are not idempotent
Events can be delivered more than once. A receiver that posts an invoice per event eventually posts two, and the reconciliation happens in finance rather than in code.
Failures are silent
No dead-letter queue, no alerting. A transient failure drops a document and nobody finds out until a customer asks where their contract is.
Sandbox and production keys got mixed up
Sandbox has its own much lower rate ceiling and its own data. Configuration that does not cleanly separate the two produces test documents in production or production documents in a test run.
Nobody owns it after handover
Custom integrations are software: they need a repository, tests, runbooks and somebody who will patch them. Built as a one-off project, they become an orphan within a year.
What API Development Is
Software you will own — which is the point and the cost
PandaDoc publishes a REST API covering the document lifecycle: creating documents from templates, populating fields, managing status, sending for signature, and webhooks for real-time event notification. Official SDKs are available in Python, Node.js, Java and PHP, alongside a Postman collection. Anything both PandaDoc's API and your other systems' APIs expose is reachable — the method has no ceiling on complexity, which is exactly why it is the last option rather than the first.
The honest trade-off. Custom development is the only route to generating from custom objects, running bulk or scheduled generation, embedding document experiences inside your own application, or enforcing logic no rules engine can express. It is also the only route that leaves you with a codebase, a deployment, a dependency on API versions, and an ongoing maintenance commitment. We quote the build and we are explicit about the run cost, because a cheap build with no owner is the expensive option.
Before you get here. Most requirements described to us as API work turn out to be configuration. Our integration services page covers what native connectors and iPaaS can do, and it can do more than most teams assume. We would rather send you there than build something you did not need — the rule of thumb is that if the requirement does not contain "from a custom object", "in bulk" or "inside our app", it is probably not an API project.
Three roles, separated. PandaDoc provides the API, the SDKs and the webhook infrastructure. Your platform team owns the hosting, the secrets and the deployment pipeline. Twopir designs and builds the integration service, instruments it, tests the failure paths, documents it and hands it over with the runbooks.
Advise, build, or build and run
Three ways teams engage us on API work, depending on what they have in-house. The first one is often enough.
Advise
For teams with their own engineers who want the design right and the traps named before they start.
- Feasibility assessment against the API surface
- Confirmation of whether configuration would suffice
- Integration design and data-model mapping
- Rate-limit and volume modelling for your throughput
- Failure-mode analysis and retry strategy
- Code review of your team's implementation
Build
We design and build the integration service, instrument it, test it and hand it to your team with documentation.
- Document service built against the REST API
- Webhook receiver with idempotent event handling
- Retry, back-off and dead-letter handling
- Rate-limit-aware queueing and scheduling
- Automated tests including the failure paths
- Runbooks, documentation and a technical handover
Build & Run
We build it and keep it working — the right answer when you have no team to hand it to.
- Everything in Build, plus ongoing ownership
- Monitoring, alerting and incident response
- API version and deprecation tracking
- Capacity review as volume grows
- Enhancement work within a retainer
- Documented exit so you are never locked in
| Requirement | Native connector | iPaaS | Custom API |
|---|---|---|---|
| Generate from an Opportunity or Deal | Yes | Partial | Yes — unnecessary |
| Generate from a custom object | No | No | Yes — the usual reason |
| Populate a template with live record data | Yes | No | Yes |
| Bulk or scheduled generation | No | Rate limited | Yes |
| Embed signing in your own product | No | No | Yes — JavaScript SDK |
| React to a status change | Yes | Yes | Yes — when logic is complex |
| Enforce logic the rules engine cannot state | No | No | Yes |
| Connect a system with no connector | No | Sometimes | Yes |
Read the rows top to bottom and stop at the first one that describes your requirement. If it is answered by either of the first two columns, you do not need this page.
The boundary, in one sentence: the API is the right answer when a connector genuinely cannot reach the requirement — and the wrong answer when it can, because the API is the only option that leaves you maintaining software. We check the configuration route first, every time, and say so when it wins.
The six components of a durable integration service
The first two are what teams ask for. The last four are what makes it survive.
Document Generation Service
The core: creating documents from templates with data from wherever it actually lives.
- Creation from templates with full field population
- Generation from custom objects and non-CRM sources
- Template selection driven by business rules
- Async creation handled correctly, with polling or webhooks
- Recipient, role and signing-order assignment
Webhook Receiver & Event Handling
Status events arriving reliably and being processed exactly once.
- HTTPS endpoint returning within the response budget
- Idempotent handling so redelivery is safe
- Signature verification on inbound events
- Event ordering and late-arrival handling
- Fast acknowledgement with asynchronous processing behind it
Resilience & Rate-Limit Handling
The difference between an integration that works and one that works at quarter-end.
- Queueing and throttling against per-endpoint limits
- Exponential back-off on 429 and transient errors
- Dead-letter queue so nothing is silently dropped
- Circuit breaking when a dependency is down
- Volume modelling against your real peak, not your average
Embedded Document Experiences
Signing and document review inside your own product, rather than a redirect to somebody else's domain.
- Embedded signing via the JavaScript SDK
- Document creation triggered from your own UI
- Session and permission handling
- Branding consistent with your product
- Fallback behaviour when embedding is unavailable
Observability & Operations
An integration you cannot see inside is an incident waiting for a deadline.
- Structured logging with correlation IDs
- Metrics on throughput, latency, errors and retries
- Alerting on dead letters and error-rate thresholds
- Runbooks for each failure mode we designed for
- Dashboards your on-call team can actually read
Testing, Documentation & Handover
Because this is software, and software without tests and documentation becomes an orphan.
- Automated tests covering the failure paths
- Sandbox environment separated from production cleanly
- API version and deprecation tracking
- Architecture and data-flow documentation
- Technical handover to your engineers, with a code walkthrough
What we actually work with
Named surfaces, what each is for, and the constraint that matters on it.
PandaDoc REST API
Document creation from templates, field population, status management, send and e-signature requests. Creation is asynchronous, so a correct client either polls for readiness or waits on a webhook rather than assuming.
PandaDoc webhooks
Document lifecycle events delivered to your HTTPS endpoint, which must acknowledge within the documented response budget. Processing goes behind the acknowledgement, not in front of it.
Official SDKs
Python, Node.js, Java and PHP, plus a Postman collection. We use the SDK where it fits your stack and a plain HTTP client where it does not — either works against the same API.
Sandbox & production keys
Sandbox keys are available on higher plan tiers with the developer centre enabled, and carry a much lower rate ceiling than production. Clean separation between the two is a design requirement, not a convention.
Salesforce REST API & Platform Events
Standard and custom objects, with Platform Events and Change Data Capture for event-driven sync. Salesforce's own API allocation is edition-dependent and needs checking alongside PandaDoc's.
HubSpot APIs & webhooks
CRM objects, associations and workflow actions, with HubSpot's own rate limits factored into the throughput model.
Your middleware & hosting
The integration service runs in your environment on your deployment pipeline. We build to your platform standards rather than introducing a stack your team does not run.
Monitoring & alerting stack
We instrument into whatever you already use — we are not going to ask you to adopt a new observability tool for one integration.
Five phases, and the first one might end the project
Phase 01 exists to establish whether you need custom development at all. It is the cheapest phase and it has the highest chance of saving you the other four.
Feasibility & Configuration Check
We confirm the requirement genuinely cannot be met by a native connector or iPaaS, then map it against what the APIs expose. Teams regularly leave this phase with a configuration answer and no development project.
Architecture & Volume Design
Data-model mapping, event flow, authentication model and the throughput profile. Rate limits are modelled against your real peak here, because that is the number the design has to hold.
Build & Instrument
The service is built with retry, idempotency, dead-lettering and observability designed in from the start rather than added after the first incident.
Failure-Path Testing
We test what happens when things go wrong: rate limiting, duplicate webhook delivery, partial failures, API errors, the dependency being down. This phase is why the integration survives.
Deploy, Document & Hand Over
Production deployment, runbooks, architecture documentation and a code walkthrough with your engineers — or onto a Build & Run retainer if you have nobody to hand it to.
What we have built and connected
Real engagements, with the scope each number was measured against.
Webhook-Driven Status Synchronisation
Bi-directional document status sync into Salesforce · 500+ documents a month
Real-time
Sent, viewed, signed, completed
2-way
Status synchronisation
0
Manual exports in the workflow
500+
Documents a month handled
Proposal creation used to take a rep 45 minutes of copying data, fixing formatting, and hoping nothing was wrong by the time it reached the customer. Now they click one button inside Salesforce and a fully accurate, branded document is ready to send in under a minute.
Salesforce · Chargebee · PandaDoc
Connecting a signed quote to subscription creation and billing status writeback
3
Systems in one integrated path
2-way
CRM synchronisation
0
Re-keying between quote and billing
1
Authoritative deal value
Engagement scope: accepted quote line items drive subscription creation in Chargebee, with billing status returning to the Salesforce Opportunity. Outcome metrics for this engagement are being confirmed with the client before publication.
Teams who have already hit the connector's edge
If you have not yet established that configuration cannot do the job, start with our integration services page instead.
Engineering leaders scoping a build
You need a realistic estimate, an honest view of the maintenance cost, and the failure modes named before you commit team capacity.
Product teams embedding signing
Documents and signature inside your own application rather than a redirect. That is the JavaScript SDK and it is genuinely only reachable this way.
Teams generating from custom objects
Your process runs on a custom object the connector does not surface. This is the single most common legitimate reason to be on this page.
Companies with high-volume document runs
Mass renewals, policy updates, quarter-end pushes. Volume at that scale needs queueing and back-off designed in, not added after the first 429.
Teams inheriting an integration that breaks
Somebody built it, it works most of the time, and nobody knows why it fails. We audit, instrument and stabilise these regularly.
Architects planning a document platform
You are designing something documents are part of, and you want the integration boundaries right before anyone writes code.
We will tell you not to build it
The most valuable thing we do on this page is send teams back to configuration when configuration would work.
Phase 01 can end the project
We check the configuration route first, every time. A client who leaves feasibility with a connector answer and no build has had the best possible outcome from this engagement.
We design for the failure paths
Rate limits, duplicate delivery, partial failures and dependency outages are designed for in Phase 02 and tested in Phase 04. That is what separates a demo from an integration.
We are honest about the run cost
Custom integrations are software. They need a repository, tests, runbooks, version tracking and an owner. We quote that alongside the build rather than after it.
We know both ends of the integration
As a Salesforce Partner and HubSpot Partner we model both platforms' API allocations, not just PandaDoc's — and the CRM side is usually the tighter constraint.
We build in your stack
Your language, your hosting, your deployment pipeline, your observability tooling. We are not going to leave you with a service nobody on your team can operate.
40+ consultants including integration engineers
Across 250+ deployments and 500+ clients over 12+ years.
What engineering teams ask before committing to a build
The technical questions that decide feasibility, effort and run cost.
Yes, but only through the API. The native integration surfaces documents at the Opportunity, Account and Contact level, so a process running on a custom object is outside what configuration can reach. The build is a service that listens for the Salesforce event, calls PandaDoc's create-from-template endpoint with the mapped field data, and handles the asynchronous creation properly. It is very achievable and it is a development project with a maintenance cost — which is why we scope it explicitly rather than describing it as an option.
No, and assuming otherwise is the most common defect we find in existing integrations. The creation endpoint is asynchronous: the call returns before the document is ready. A correct client either polls for the status change or waits on a webhook. Code written against the synchronous assumption passes testing with one document and fails the first time the queue is under load.
By designing for them rather than discovering them. PandaDoc enforces per-endpoint rate limits and returns HTTP 429 when exceeded, and the sandbox environment has a much lower ceiling than production. We model your peak throughput — not your average — in Phase 02, then build queueing, throttling and exponential back-off into the service. Salesforce and HubSpot have their own allocations, and on high-volume integrations the CRM side is usually the tighter constraint.
Be reachable over HTTPS and acknowledge quickly — PandaDoc expects an HTTP 200 within a short documented window. That means the endpoint acknowledges first and processes afterwards, never the reverse. It also has to be idempotent, because events can be delivered more than once: a receiver that creates an invoice per event will eventually create two, and that becomes finance's problem rather than engineering's.
PandaDoc publishes official SDKs in Python, Node.js, Java and PHP, along with a Postman collection. Use whichever matches the stack your team already operates. If your language is not on that list, the REST API works with any HTTP client and you lose very little — the SDKs are convenience wrappers rather than the only supported path.
A single-purpose service — generate from one custom object, handle status webhooks — is typically a few weeks including failure-path testing. Multi-system orchestration with billing and transactional guarantees, or an embedded document experience inside your product, runs longer. The initial build is weeks rather than hours in every case, and anyone quoting days has not scoped the failure handling.
That depends on volume and how many systems it touches, but it is never zero, and we will give you a real figure rather than leaving it implied. A custom integration needs a repository, tests, monitoring, API version tracking and somebody who will respond when it alerts. Teams without that capacity should look at our Build & Run tier rather than taking delivery of software they cannot operate.
Yes, and it is a regular engagement. We start by instrumenting it, because the first problem is almost always that nobody can see what it is doing. From there the usual findings are missing idempotency, no back-off on rate limits, and no dead-letter handling. Adding those to a working service is normally much cheaper than a rebuild, and we will tell you when it is not.
Next Step
Before you build it, let us check you have to
Send us the requirement. If a connector or an iPaaS recipe can do it, we will tell you that and point you at the cheaper route. If it genuinely needs code, you will get an honest estimate that includes what it costs to keep running.
12+ years · 500+ clients · 40+ consultants · Salesforce Partner · HubSpot Partner
