← Back to blog

Extract Structured Data from Documents in Make.com

Pattern guide for Make.com × Cryvis: sources, document endpoints, and destinations—with ASCII workflows for finance, KYC, and custom PDFs.

Make scenarios for document extraction share one skeleton: source → download binary → Cryvis HTTP → map JSON → destination. The only variable that must stay accurate is the Cryvis URL and multipart field names. Wrong endpoint = wrong schema.

This post is a pattern catalog, not a single tutorial. Pair it with the decision guide in Extract PDF data and the Make hub at Make.com + Cryvis.

The universal skeleton

[Trigger / Watch]
      |
      v
[Get file binary] ---- MIME pdf/jpeg/png/webp
      |
      v
[HTTP POST Cryvis]
  Authorization: Bearer ...
  multipart fields per endpoint
      |
      v
[Parse success / data|results / meta]
      |
      +----> [Filter / Router]
      |
      v
[Destination: Sheets, CRM, Slack, DB, webhook]

Credits: 1 per page / image. No generic /ocr route—only /v1/documents/<type> or /v1/custom-extractors/<slug>.

Sources × endpoints × destinations

Source (Make)Typical documentCryvis endpointDestination examples
Google Drive WatchInvoice PDF/v1/documents/invoiceSheets, QuickBooks webhook
Gmail attachmentReceipt photo/v1/documents/receiptExpense Sheet, Slack
Dropbox / OneDriveUtility PDF/v1/custom-extractors/:slugAirtable, Notion DB
Typeform / webhook file URLPassport scans/v1/documents/passportCRM contact + KYC flag
Mobile upload → DrivePAN / Aadhaar/v1/documents/pan or aadhaarOnboarding Sheet
Fleet ops folderRC front/back/v1/documents/indian-vehicle-rcFleet Airtable

Identity and vehicle field references live on their product pages: Passport, PAN, Aadhaar, Driver’s license, Indian RC. Finance: Invoice, Receipt. Custom: Custom.

Pattern 1 — Finance inbox

Gmail Watch (label: invoices)
  → Iterator (attachments)
  → Filter (pdf|jpeg|png|webp)
  → HTTP invoice OR receipt (Router by subject/folder)
  → Sheets Add Row
  → Slack Notify (optional)

Invoice single-file responses use data.*. Receipt multi-file batches use results[]—iterate results before Sheets (parse responses).

Pattern 2 — KYC pack

Drive folder: /kyc/incoming
  → Download
  → Router by filename prefix
       pan_*     → POST .../pan          (file)
       aadhaar_* → POST .../aadhaar      (file ×1–2)
       ppt_*     → POST .../passport     (first_page + last_page)
       dl_*      → POST .../driver-license (file + country)
  → CRM Update contact
  → Archive file to /kyc/processed

Passport never uses a single file field. RC never uses file either—use front / back (multipart guide).

Pattern 3 — Custom ops documents

Dropbox Watch
  → Download
  → HTTP POST /v1/custom-extractors/bill-of-lading
  → Filter: meta.validation.is_valid = true
       true  → Airtable Create record
       false → Slack #ops-review + Break

Schema and Make HTTP setup: Convert PDFs to JSON, Build custom extractor.

Pattern 4 — Scheduled backfill

Schedule (nightly)
  → Sheets Search rows (status = pending)
  → Iterator
  → Drive Download by file_id column
  → HTTP Cryvis
  → Sheets Update row (status = done, request_id = meta.request_id)

Useful when humans drop files during the day and you want a single controlled credit burn window.

Mapping rules that transfer across patterns

  1. Always map from binary modules, not share links (upload binary).
  2. Put Bearer auth in one place (Bearer authentication).
  3. Nested JSON (seller.name, merchant.name, mrz.line1) maps as collections (map fields).
  4. Soft validation ≠ error. Check meta.validation.warnings even on HTTP 200 (errors).
  5. Clone scenarios per document type faster than overloading one Router with twelve HTTP modules—unless volume is low and ops prefer one canvas.

Endpoint cheat sheet (copy into Make)

Invoice:          POST https://api.cryvis.com/v1/documents/invoice
Receipt:          POST https://api.cryvis.com/v1/documents/receipt
Passport:         POST https://api.cryvis.com/v1/documents/passport
PAN:              POST https://api.cryvis.com/v1/documents/pan
Aadhaar:          POST https://api.cryvis.com/v1/documents/aadhaar
Driver license:   POST https://api.cryvis.com/v1/documents/driver-license
Indian RC:        POST https://api.cryvis.com/v1/documents/indian-vehicle-rc
Custom:           POST https://api.cryvis.com/v1/custom-extractors/<slug>

Full REST connection pattern: Connect a REST API in Make.com. Concrete invoice HTTP walkthrough: Send PDF to OCR API (invoice endpoint—not a fictional OCR path).

Choosing destinations

NeedDestination module tip
Audit trailSheets + meta.request_id column
Human reviewSlack with vendor/name + Drive link
System of recordCRM/Airtable keyed by document number
Downstream APIHTTP to your backend with Cryvis data as body

Do not write raw OCR text into the CRM when Cryvis already returned structured fields—map typed keys only (specific fields).

Anti-patterns

  • One HTTP module pointed at a guessed /v1/pdf-ocr URL
  • Reusing invoice mappings for a custom extractor response
  • Sending passport pages as one PDF without splitting into first_page / last_page when you have two images
  • Ignoring credit cost on 20-page scanned PDFs full of blank pages

Next steps

Pick one pattern above, wire a single document type end-to-end, then expand the Router. Start with Invoice API or Custom extractors, and keep the Make hub bookmarked for the rest of the cluster.