How to automate PDF extraction with Make webhooks

Make is a strong fit for PDF workflows because PDFs usually need branching. One path handles ready documents, one path handles failures, one path writes rows, and another path notifies a reviewer.

This is API-feasible today. Make’s Webhooks and HTTP integration includes Custom webhook triggers and HTTP request actions. That is enough to use okraPDF both ways: Make can send PDFs into okraPDF, and okraPDF can send processing events back into Make.

Scenario shape

Use two scenarios for a production workflow.

Scenario	Trigger	Purpose
Ingest PDFs	Gmail, Drive, Dropbox, form upload, or HTTP	Upload file to okraPDF
React to PDF status	Make Custom webhook receiving okraPDF event	Route ready or failed results

Separating ingest from status keeps the workflow honest. Upload success does not mean extraction is complete.

Scenario 1: upload PDFs to okraPDF

Create a Make scenario with a source module:

• Google Drive: Watch files in a folder
• Gmail: Watch emails or attachments
• Dropbox: Watch files
• Webhooks: Custom webhook for external uploads

Add filters:

• Filename ends with .pdf
• MIME type is PDF when available
• File size is under your okraPDF limit
• File ID has not already been processed

Then add an HTTP module:

1. Method: POST.
2. URL: your okraPDF upload endpoint.
3. Authorization: okraPDF API key.
4. Body: file or URL, depending on your source module.
5. Response fields to keep: document ID, job ID, hosted URL, poll URL.

Write those IDs back to your tracking system before the scenario ends.

Scenario 2: receive okraPDF lifecycle events

Create another Make scenario:

1. Trigger: Webhooks > Custom webhook.
2. Copy the generated webhook URL.
3. In okraPDF webhook settings, create an endpoint with that URL.
4. Select document.processed and document.failed.
5. Save the okraPDF signing secret.

Send a test PDF through the upload scenario. Make should receive an event envelope with type, created_at, and data.

Add routing

Add a Router after the webhook trigger.

Route 1: type = document.processed

• Parse extracted fields.
• Append rows to Google Sheets.
• Update Airtable or CRM.
• Send a human review Slack message if confidence is low.

Route 2: type = document.failed

• Create an exception row.
• Notify operations.
• Include filename, document ID, error, and source URL.

Route 3: optional type = document.created

• Write an intake log only.
• Do not assume extraction is ready.

Mapping extracted rows

Keep the Make mapping layer small. Transform okraPDF output into a stable row object:

{
  "document_id": "...",
  "filename": "invoice.pdf",
  "vendor_name": "Acme Supply",
  "invoice_number": "INV-1042",
  "total": "4820.19",
  "hosted_url": "https://..."
}

For arrays, use Make’s iterator before the destination module. For nested objects, flatten only the fields the destination needs.

Security checklist

Use a dedicated okraPDF API key for Make. Name it clearly, such as make-prod-ap-intake. Rotate it if the Make scenario is cloned or shared.

If you accept okraPDF webhooks in Make, store and verify the signing secret when you have a custom verification step. If you skip signature verification in a no-code setup, keep the webhook URL private and prefer low-risk destinations.

Operational checklist

Add a data store or destination lookup for idempotency. Make scenarios can retry. If the destination is Google Sheets or Airtable, use okraPDF document ID as the unique key.

Log skipped files. The team should know whether a file was skipped because it was not a PDF, too large, already processed, or failed extraction.

Keep one scenario per business workflow. A single mega-scenario for invoices, W-9s, bills of lading, and statements becomes difficult to debug.