
Post: Automate PandaDoc Status Tracking with Make.com Webhooks
PandaDoc webhooks push real-time document status events to Make.com™ the instant they fire. Connect a Custom Webhook trigger, parse the JSON payload, filter by event type, and branch into parallel routes: one writes every event to a timestamped compliance log, the other notifies your HRIS and Slack only when action is required.
For context on when HR teams need this architecture, see 11 signs it’s time to automate your HR documents with PandaDoc and Make. For a broader look at scenario structure, see Make.com scenarios for HR document management.
Snapshot: Context, Constraints, and Outcomes
| Factor | Detail |
|---|---|
| Organization | Regional healthcare system, 400–600 employees |
| Primary stakeholder | HR Director |
| Baseline problem | 12 hours/week consumed by manual document status checking and follow-up across offer letters, onboarding packets, and policy acknowledgments |
| Constraints | No dedicated IT support; compliance audit requirements for timestamped document events; existing PandaDoc Business plan |
| Approach | PandaDoc webhooks → Make.com™ Custom Webhook trigger → JSON parser → event-type filters → parallel logging and HRIS update routes |
| Build time | One day (initial build and testing) |
| Outcome | 6 hours/week reclaimed; average document-to-completion time reduced 60%; zero missed-signature incidents in 90-day post-launch window |
Context and Baseline: What Manual Document Tracking Actually Costs
The HR team managed a high-volume hiring cycle — 40 to 60 active candidates at any point, each requiring at least three sequenced documents: offer letter, background authorization, and onboarding packet. Every document sat in PandaDoc. Every status check required a human to open the platform, scan the dashboard, and decide whether to send a follow-up.
That process repeated across the team multiple times daily. Conservatively, 12 hours per week were consumed by this coordination loop — time that produced no document, no decision, and no candidate experience value. It was pure overhead.
The downstream consequences were measurable. When signatories were not followed up promptly, start dates slipped. When policy acknowledgments were delayed, compliance windows closed. The problem was not effort — it was architecture. A deterministic, rules-based task (check status, send reminder if unsigned after X hours) was being handled by a human instead of a system.
Expert Take
Manual document follow-up is the most common hidden cost we find in HR operations audits. It is always rules-based, always predictable, and always the first thing that should run on a machine. The teams that reclaim the most time are not the ones with the best tools — they are the ones who stop tolerating work that a webhook executes automatically.
Approach: Webhook Architecture Over Polling
Two approaches exist for connecting PandaDoc status data to external systems: polling (scheduled checks against the PandaDoc API at set intervals) and webhooks (event-driven pushes that fire the instant a status changes). Polling introduces lag, consumes API rate limits, and requires a scheduled trigger. Webhooks are instantaneous, resource-efficient, and require nothing to kick them off — making them the right architecture for any document pipeline where timing matters.
The design chosen was a four-layer Make.com™ scenario:
- Custom Webhook trigger — listens for all incoming PandaDoc event payloads
- JSON parser module — structures the raw payload into addressable data fields (document ID, document name, recipient email, event type, timestamp)
- Router module with event-type filters — branches the flow by event type so high-signal events (Signed, Completed) and low-signal events (Viewed, Sent) route to separate action chains
- Parallel action modules — Route A writes every event to a timestamped compliance log; Route B updates the HRIS and sends a Slack notification only on Signed/Completed events
This design — separate routes for logging versus notification — is the difference between an automation that becomes noise and one that stays trusted. For more on how to structure Make.com™ scenarios for maximum HR signal quality, see Make.com features that elevate HR automation.
Implementation: Step-by-Step Configuration
Phase 1 — Define Tracked Events and Data Requirements
Before touching PandaDoc or Make.com™, document exactly which status transitions matter and what data each downstream system needs. This planning step prevents scope creep during build.
- Tracked events: Document Sent, Document Viewed, Document Signed, Document Completed, Document Declined, Document Expired
- Required payload fields: document_id, document_name, recipient_email, event_type, event_timestamp, template_name
- Downstream targets: Google Sheets (compliance log, all events); HRIS (update candidate record on Signed/Completed); Slack (HR channel alert on Signed/Completed and Declined/Expired)
Phase 2 — Configure PandaDoc Webhooks
Inside PandaDoc workspace settings, navigate to Integrations → Webhooks and create a new webhook endpoint. At this stage, the Make.com™ listener URL is not yet available — leave the URL field open and proceed to Phase 3 to generate it. Select all six event types identified in Phase 1 and set the webhook to Active.
PandaDoc webhooks fire for all documents in the workspace by default. If the workspace contains non-HR documents, add a template-name filter in Phase 4 to scope the Make.com™ scenario to HR-relevant templates only.
Phase 3 — Build the Make.com Scenario and Generate the Listener URL
In Make.com™, create a new scenario and set the trigger module to Webhooks → Custom Webhook. Save the module — Make.com™ generates a unique HTTPS listener URL. Copy that URL and paste it into the PandaDoc webhook configuration from Phase 2. Save both.
Test the connection by changing the status of a test document in PandaDoc. Make.com™ catches the payload and displays the raw data structure. This auto-detection step is critical — Make.com™ uses the sample payload to map all available fields for use in downstream modules.
Phase 4 — Parse and Filter the Payload
Add a JSON module immediately after the webhook trigger and map it to the body of the incoming payload. All PandaDoc fields — document_id, event_type, recipient details, timestamps — are now individually addressable throughout the scenario.
Add a Router module next with two routes:
- Route A (High-Signal): Filter condition: event_type equals ‘document_signed’ OR event_type equals ‘document_completed’ OR event_type equals ‘document_declined’ OR event_type equals ‘document_expired’
- Route B (All Events — Log Only): No filter condition; catches every event for compliance logging
This is the leverage point. Every document event goes to the compliance log. Only actionable events reach the HRIS and Slack. The signal-to-noise ratio in downstream systems stays high indefinitely. The same router-and-filter pattern applies across all document types — see essential PandaDoc features for HR automation for configuration walkthroughs across offer letters, NDAs, and background authorizations.
Phase 5 — Configure Action Modules
Route B (Compliance Log): Add a Google Sheets → Add Row module. Map columns: Timestamp (event_timestamp field), Document ID, Document Name, Recipient Email, Event Type, Template Name. Every status change for every document writes a permanent, timestamped row. No manual record-keeping required.
Route A — HRIS Update: Add an HTTP or native HRIS module to update the candidate record. Map document_id to the corresponding candidate and set the status field to the event_type value. This keeps the HRIS current without manual entry — directly eliminating the class of errors covered in critical PandaDoc HR automation mistakes.
Route A — Slack Notification: Add a Slack → Send Message module and compose the message dynamically: “Document [document_name] has been [event_type] by [recipient_email] at [event_timestamp].” Target the HR operations channel. For Declined and Expired events, add a second Slack message to a separate escalation channel.
Phase 6 — Add Error Handling
Add an error handler route configured to send a Slack alert to a technical channel whenever a module fails. Common failure points are HRIS authentication timeouts and Google Sheets quota limits during high-volume periods. The error handler ensures no status change is silently lost. For a full breakdown of where Make.com™ scenarios break in HR environments, see critical Make.com mistakes to avoid in HR automation.
Activate the scenario and set scheduling to run continuously (webhook-triggered, not scheduled). The scenario is now live.
Results: Before and After
| Metric | Before | After |
|---|---|---|
| Hours/week on document status checks | ~12 hours | ~0 hours (automated) |
| Average document-to-completion time | Baseline | 60% reduction |
| Missed-signature incidents (90 days post-launch) | Multiple per month | Zero |
| Compliance log completeness | Manual, incomplete | 100% automated, timestamped |
| HRIS update lag (post-signature) | Hours to days (manual) | Under 60 seconds (automated) |
| Build time | — | One day |
The six hours reclaimed weekly translated directly into strategic HR capacity. The team redirected that time toward candidate experience improvements and manager coaching — work that requires human judgment and cannot be automated. That reallocation, from low-value coordination to high-judgment work, is the primary driver of automation ROI in knowledge-work environments.
Lessons Learned: What to Do Differently
1. Build the compliance log first, not last
The compliance log was added in Phase 5 as a Route B action. It should be the first module after the JSON parser — a universal capture that runs before any filtering. That sequencing guarantees no event is ever dropped, even if a filter misconfiguration temporarily breaks a downstream route.
2. Test Declined and Expired events explicitly
During initial testing, only Signed and Completed events were tested against the filter logic. Declined and Expired events were assumed to work correctly — they did not. A typo in the event type string caused them to bypass the high-signal route. Explicit testing of every event type against every filter condition is non-negotiable.
3. Scope the webhook to document templates, not the whole workspace
PandaDoc fires webhooks for every document in the workspace, including sales proposals and vendor contracts that HR does not own. Adding a template-name filter in Make.com™ from day one prevents the compliance log from filling with irrelevant noise. Scoping by template is standard practice — treat it as a default, not an afterthought. For configuration detail, see essential PandaDoc features HR teams must master.
4. Document the scenario for the next administrator
Make.com™ scenarios are visually intuitive to their builder and opaque to everyone else. After launch, add notes to every module explaining what it does and why each filter condition is set as it is. When a new team member takes over, undocumented scenarios create a re-learning burden that a five-minute annotation habit prevents entirely.
Reusability: The Same Architecture Scales Across Document Types
The scenario built here — webhook trigger, JSON parser, router, event filters, parallel action routes — is not offer-letter-specific. The same architecture handles any document type that lives in PandaDoc:
- Onboarding packets: Route completion events to HRIS to trigger IT provisioning and benefits enrollment workflows
- Policy acknowledgments: Route signed events to the compliance log with a policy-version tag for audit readiness
- NDAs: Route completed events to the vendor management system, closing the loop on contractor onboarding
- Background check authorizations: Route signed events to the background check vendor’s API trigger
Each document type gets its own router branch. The compliance log captures all of them in a single sheet. One scenario, full pipeline visibility. For more on scaling this across the full onboarding stack, see Make.com™ automations for the employee experience. To understand where this fits in your broader automation investment, see 10 smart ways HR teams save with Make.com automation.
Frequently Asked Questions
What is a PandaDoc webhook and how does it work with Make.com?
A PandaDoc webhook is an outbound HTTP notification that fires automatically whenever a document changes status. Make.com™ provides a unique listener URL that receives that payload instantly, allowing downstream actions — HRIS updates, Slack alerts, spreadsheet logs — to trigger without manual checking or scheduled polling.
Which PandaDoc document events should I track?
For HR workflows, track Document Sent, Document Viewed, Document Signed, Document Completed, Document Declined, and Document Expired. Signed and Completed events trigger operational updates; Declined and Expired events trigger exception-handling and escalation routes.
Do I need coding skills to build this automation?
No. The entire integration is built inside Make.com™’s visual scenario editor using a Custom Webhook trigger, a JSON parser, filter modules, and action modules. No custom code is required. Teams with no prior automation experience complete the initial build in four to six hours.
How do I prevent notification overload in my CRM or Slack channel?
Use Make.com™ filter modules immediately after the JSON parser, set to pass only on high-value status values like ‘document.signed’ or ‘document.completed’. Route low-signal events like ‘Viewed’ to a compliance log separately without triggering any notifications.
Is this approach compliant for sensitive HR documents?
Yes. PandaDoc maintains a tamper-evident audit trail for every document event. The Make.com™ scenario adds a second layer by logging every webhook payload with a timestamp to a central Google Sheet. That dual-log structure satisfies most HR compliance requirements for offer letters, NDAs, and policy acknowledgments.
What happens if a webhook payload fails to deliver?
Make.com™ logs failed webhook deliveries in the scenario’s execution history. Configure an error handler route to send a Slack alert to a technical channel when any downstream action fails, preventing silent data gaps in the compliance log.
Can one Make.com scenario handle multiple document types?
Yes. A single scenario scaffold with a Router module handles all PandaDoc document types by branching on document template name or custom field value, keeping scenario count low and maintenance straightforward.
How long does it take to see ROI from this automation?
ROI arrives in the first week. Teams that previously spent hours manually checking document dashboards recover that time entirely once the automation is live — the webhook fires on every status change and the human loop disappears.

