Olmec Dynamics
H
·8 min read

How to Automate PandaDoc Proposals from Airtable Using Make.com (With Webhook Status Updates)

Automate PandaDoc proposal creation from Airtable using Make.com, verify webhook signatures, and update Airtable with live status changes.

Introduction

If your team still generates PandaDoc proposals by hand, the pain is predictable. Someone copies values out of Airtable, fills a PandaDoc template, sends it, then later someone else checks whether it was viewed or completed. That creates the same operational loop every week, plus errors when data is copied incorrectly or proposals get stuck in the wrong stage.

This is exactly where Cross-Platform Automation (XPA) earns its keep. In this post, you will build an Airtable to PandaDoc workflow in Make.com that generates proposals automatically, sends them for e-signature, and updates Airtable as PandaDoc statuses change via webhooks.

By the end, you will know how to implement this XPA pattern reliably, including duplicate-proofing and webhook security.

What You’ll Need

  • Airtable
    • An Proposals table with fields to store proposal data and PandaDoc identifiers
    • Permission to read and update proposal records
  • PandaDoc
    • A proposal template ready for your merge fields
    • Ability to send documents for signature via API/integration
    • Webhooks enabled for document status events
  • Make.com
    • Two scenarios, one for create-and-send and one for webhook ingestion
    • Connections for Airtable and PandaDoc
  • Slack (optional but recommended)
    • A channel where you want lifecycle alerts

Plan notes:

  • This is an advanced build. A paid Make.com plan is recommended so you can run scenarios reliably, inspect logs, and handle webhook traffic without constant throttling.

If you want the “mental model” behind Cross-Platform Automation (XPA), read Cross-Platform Automation (XPA).

How It Works (The Logic)

You are building a two-scenario XPA.

  • Scenario A (Airtable → PandaDoc → Airtable):

    • Trigger on an Airtable record reaching Ready to Send
    • Make.com creates a PandaDoc document from a template, sends it to the recipient(s), then writes back the pandaDocDocumentId
    • A filter prevents duplicates by only creating PandaDoc documents when pandaDocDocumentId is empty

  • Scenario B (PandaDoc Webhooks → Make.com → Airtable (+ Slack)):

    • PandaDoc sends webhook events to Make.com when document status changes
    • Make.com verifies the webhook signature, extracts documentId and the new status, updates the matching Airtable record, and optionally posts Slack alerts only on key transitions

Step-by-Step Setup

1) Build your Airtable schema for idempotency

In Airtable, create or update these fields in Proposals:

  • Proposal Status (single select): Draft, Ready to Send, Sent, Waiting for Signature, Completed, Denied, Error
  • pandaDocDocumentId (single line text): starts blank, gets filled after creation
  • pandaDocLastStatus (single line text): last known PandaDoc status
  • Recipient Name (single line text)
  • Recipient Email (single line text)
  • Company Name (single line text)
  • Proposal Amount (number)
  • Currency (single line text)
  • pandaDocLink (URL text, optional)

Gotcha: Scenario B needs a stable join key. pandaDocDocumentId is your join key.

2) Confirm your PandaDoc template mapping

Open the PandaDoc template and ensure the placeholders you use line up with the fields you will send from Make.com.

A practical mapping example:

  • Company Name in PandaDoc → Airtable Company Name
  • Proposal Amount and Currency → Airtable Proposal Amount, Currency
  • Recipient info → Airtable Recipient Name, Recipient Email

If your template structure expects multiple recipients or complex roles, plan how you will assemble those recipients in Make before you test.

3) Create Scenario A in Make.com (Airtable → PandaDoc → Airtable)

Create a new scenario: Airtable to PandaDoc: Create and Send.

Module sequence (conceptually):

  1. Trigger: Airtable record event (watch records changing) OR a scheduled “find eligible records” approach

    • For most teams, a watcher is cleaner, but scheduled querying works too if you filter tightly.

  2. Filter (critical): allow only records where

    • Proposal Status = Ready to Send
    • pandaDocDocumentId is empty

This is your idempotency guard. If Make retries, you do not recreate PandaDoc documents.

  1. PandaDoc: Create document from template

    • Select the PandaDoc template
    • Map Airtable fields to PandaDoc template fields

  2. PandaDoc: Send for signature

    • Provide recipient name and email from Airtable
    • If your template uses predefined signature fields, make sure your recipients match those fields

  3. Airtable: Update proposal record

    • Set pandaDocDocumentId to the created PandaDoc document id
    • Set Proposal Status to Sent (or directly to Waiting for Signature, depending on how your team labels stages)
    • Set pandaDocLastStatus to the status returned/known after sending
    • Optionally set pandaDocLink

  4. Slack (optional): post a “proposal sent” alert

    • Keep it short, include company name and the PandaDoc link

4) Add Slack routing only on key events

Do not dump lifecycle noise into Slack.

A good rule for Scenario A:

  • Post only once when you send.

Scenario B should post again only when completed or denied.

5) Create Scenario B in Make.com (PandaDoc Webhooks → Airtable)

Create a second scenario: PandaDoc Webhook Status to Airtable.

Module sequence (conceptually):

  1. Trigger: Make webhook endpoint

    • PandaDoc will call this endpoint on document status changes

  2. Signature verification step (required):

    • PandaDoc webhooks include signature data you should validate
    • Implement signature verification in Make using a code/HTTP-capable step, so you reject unauthenticated webhook payloads

Why this matters: it improves security and prevents accidental processing of spoofed events.

  1. Parse the webhook payload

    • Extract:
      • PandaDoc documentId (or equivalent id field)
      • event status / document status field

  2. Airtable: Find proposal by pandaDocDocumentId

    • Use pandaDocDocumentId as the lookup

  3. Map PandaDoc status → Airtable Proposal Status

    • Example mapping you can implement as a switch/router:
      • document.sent → Sent
      • signature pending state (often described as waiting/approval) → Waiting for Signature
      • document.completed → Completed
      • denial/voided type states → Denied

  4. Airtable: Update record

    • Update Proposal Status
    • Update pandaDocLastStatus
    • Optionally store the most recent event timestamp for auditing

  5. Slack (optional): route only key transitions

    • Post when Proposal Status becomes Completed or Denied

For webhook lifecycle concepts and status change patterns, reference PandaDoc’s workflow and webhook documentation, like PandaDoc document workflow automation concepts and PandaDoc webhooks concepts.

6) Test end-to-end with a real Airtable record

Run tests in this order:

  1. In Airtable, set one record to Ready to Send and keep pandaDocDocumentId empty
  2. Confirm Scenario A creates and sends the PandaDoc document
  3. Confirm Airtable gets pandaDocDocumentId
  4. Trigger a webhook by moving the document through real recipient actions (or simulate as allowed)
  5. Confirm Scenario B updates Proposal Status and only posts Slack on completed/denied

7) Add operational visibility fields

If you want this to run without “tribal knowledge”, add fields like:

  • pandaDocWebhookLastReceivedAt
  • pandaDocWebhookEventId (if payload provides it)
  • pandaDocProcessingResult (success/failure)

This mirrors the kind of reliability thinking you would use in other Make.com reporting pipelines like the daily Airtable status digest to Gmail.

Real-World Business Scenario

A B2B consultancy uses Airtable to collect scope inputs and pricing details. When a lead moves to Ready to Send, Make.com generates a PandaDoc proposal from the correct template and sends it for signature.

As the client signs, PandaDoc webhooks push status updates back into Airtable. Ops and sales can open one Airtable view and see the exact lifecycle state, and Slack only lights up on Completed and Denied.

Outcome:

  • fewer missed follow-ups
  • no duplicate proposals caused by retries
  • a single source of truth for proposal status, with auditable identifiers (pandaDocDocumentId)

Common Variations

1) Generate different templates from the same Airtable record

Add Template Choice to Airtable and route Scenario A to the right PandaDoc template before creating the document.

2) Add an escalation workflow for proposals waiting too long

When Proposal Status becomes Waiting for Signature, schedule an additional Make.com path to post a reminder after X days, similar in structure to exception workflows like routing operational alerts from Shopify orders to Google Sheets and Slack.

3) Archive the completed document into Airtable or Drive

On Completed, store the PandaDoc link or fetch final document metadata and write it back into Airtable so your team has it in the same place they manage the deal.

A proposal pipeline you can trust

You built a two-part XPA: Scenario A creates and sends PandaDoc documents from Airtable with idempotency, and Scenario B keeps Airtable proposal status in sync using verified PandaDoc webhook updates.

If you want the same pattern tailored to your PandaDoc templates, your Airtable schema, and your exact status labels, Olmec Dynamics builds these automations for real operations teams. You can see what we do at Olmec Dynamics.