Extract Specific Fields from PDFs in Make.com

Most Make destinations need five columns, not fifty. Cryvis custom extractors let you declare exactly those fields in JSON Schema, validate them, and map only those keys from data into Sheets, Airtable, or your CRM.

This is not “tell OCR to ignore the rest of the page.” The model still sees the document; the schema constrains output. Built-in APIs (Invoice, Receipt, etc.) return fixed schemas—trim in Make mapping if you use those. For arbitrary PDFs, custom schemas are how you shrink the contract.

Docs: Custom extractor schemas. Product: Custom API. Hub: Make.com + Cryvis.

Why field design beats post-filtering

Wide schema (40 keys)          Narrow schema (6 keys)
        |                              |
        v                              v
  Large JSON bundle              Small JSON bundle
        |                              |
        v                              v
  Map 6 of 40 in Make            Map 6 of 6 in Make
  (easy to mis-map)              (harder to screw up)

Narrow schemas also make additionalProperties: false more useful—unexpected keys surface as validation issues instead of silent clutter.

Step 1 — List destination columns first

Write the Make destination before the schema:

Anything not in this table should not enter properties unless you need it for a Router filter later (e.g. document_language).

Step 2 — Write descriptions that extract well

The model uses field description text. Prefer:

"po_number": {
  "type": ["string", "null"],
  "description": "Customer purchase order number, often labeled PO or P.O.",
  "pattern": "^[A-Z0-9-]+$",
  "x-cryvis-validation": "hard"
}

Avoid empty descriptions or labels like "field1". Nullable unions keep missing values as JSON null instead of failing the whole call when the field is soft or optional.

Step 3 — Soft vs hard for Make routing

Mark identifiers hard (po_number, account_number). Mark OCR-noisy dates, emails, and amounts soft unless finance requires a hard stop.

required + hard → missing field fails. required + soft → warning and null.

Step 4 — Call from Make and map only needed keys

HTTP POST /v1/custom-extractors/<slug>
  -F file=@doc.pdf
        |
        v
data.po_number -----> Sheets!A
data.vendor_name ---> Sheets!B
data.amount_due ----> Sheets!C
meta.request_id ----> Sheets!Z (audit)

Do not map the entire data collection into a single cell “for later.” You will re-parse it forever. If you need raw JSON for debugging, store meta.request_id and re-fetch from your own logs—or temporarily map data to a staging column, then delete it.

Binary upload: Upload file to API. Full builder flow: Build custom extractor. PDF → Sheets: Convert PDFs to JSON.

Nested objects: extract groups, map leaves

If the destination needs vendor name and tax id:

"vendor": {
  "type": ["object", "null"],
  "description": "Supplier block",
  "properties": {
    "name": {
      "type": ["string", "null"],
      "description": "Supplier legal name"
    },
    "tax_id": {
      "type": ["string", "null"],
      "description": "VAT/GST/EIN if present"
    }
  },
  "additionalProperties": false,
  "x-cryvis-validation": "soft"
}

In Make map data.vendor.name and data.vendor.tax_id—not the whole vendor collection—unless the destination accepts JSON. Nested mapping: Map API JSON fields.

Arrays: only when the destination iterates

Line items belong in schema when you Iterator them into child rows. If Sheets only stores a total, put total_amount in the schema and omit line_items entirely. That is the highest-leverage “specific fields” decision.

Built-ins: map subset without a custom schema

On invoice responses you can ignore line_items and only map:

• data.invoice_number
• data.seller.name
• data.total_amount
• data.due_date

Same idea—specific fields—implemented in the mapping panel instead of schema. Prefer built-ins when the document type matches (decision guide).

Null handling in Make

Cryvis returns JSON null for missing nullable fields. In mapping use ifempty(data.due_date; ) or leave blank. Do not coerce null to 0 for amounts unless your finance rules say so—zeros hide “not found.”

Validation warnings as a second field set

Treat meta.validation as metadata you may map:

• meta.validation.is_valid → boolean column
• meta.validation.warnings → join to text for Slack
• meta.request_id → support ticket reference

Parse envelopes: Parse API JSON responses. Errors: Handle API errors.

Checklist

• Destination columns listed before schema write
• Every property has a clear description
• Hard reserved for true blockers
• Arrays only if Make iterates them
• Make maps leaf paths, not unused siblings
• Console test sample reviewed for warnings

Ship the smallest schema that makes the automation correct. Expand later when a new destination column appears—not because the PDF has more ink.