Extract PDF Data in Make.com with Cryvis

Cryvis does not expose a generic “PDF OCR” URL. Every PDF must hit a document-type endpoint or a custom extractor. Pick wrong and you either get a schema that does not match the document, or you invent an API that does not exist.

This guide is the decision tree for Make.com scenarios: when to use Invoice, Receipt, identity APIs, or a custom extractor—plus a concrete Google Drive → Cryvis Invoice → Sheets path.

Browse the full Make hub: Make.com + Cryvis.

There is no generic PDF OCR endpoint

PDF / image upload
        |
        v
+------------------+     known type?      +---------------------------+
| What document is |---- yes ------------>| POST /v1/documents/<type> |
| this?            |                      | multipart field(s)        |
+------------------+                      +---------------------------+
        | no / odd layout
        v
+------------------------------------------+
| POST /v1/custom-extractors/<your-slug>   |
| multipart: file                          |
+------------------------------------------+

Supported MIME types on all of these routes: application/pdf, image/jpeg, image/png, image/webp. Credits: 1 per PDF page or 1 per image. Auth: Authorization: Bearer <API_KEY>.

If you are searching for “send PDF to OCR API in Make,” the HTTP module still needs a real Cryvis path—see Send a PDF to Cryvis from Make.com.

Decision guide: which endpoint?

Rule of thumb: if the PDF is a standard commercial invoice or receipt, use the built-in. If your team designed the form, or vendors invent new layouts that are not invoices, build a custom schema in Console and call that slug from Make’s HTTP module.

Related deep-dives:

• Convert PDFs to JSON with a custom extractor
• Build a custom document extractor
• Extract specific fields from PDFs

Built-in vs custom in Make

Built-ins return typed fields you can map immediately (invoice_number, seller.name, total_amount, …). Custom extractors return whatever keys you put in the JSON Schema—same { success, data, meta } envelope, different data shape.

Google Drive (Watch files)
        |
        v
Router: filename / folder / mime
   |                    |
   | invoices/          | other/
   v                    v
HTTP → invoice          HTTP → custom-extractors/utility-bill
   |                    |
   v                    v
Sheets / ERP            Sheets / CRM

Use a Router when one Drive folder mixes document types. Do not send every PDF to invoice “hoping” the model invents fields—invoice is optimized for invoices.

Sample A: Drive → Invoice → Sheets

Goal: New PDF in a Drive folder becomes a row with vendor, invoice number, dates, and totals.

Modules

1. Google Drive — Watch Files in a Folder (or Watch All Files if you filter later)
2. Google Drive — Download a File (map file ID → binary)
3. HTTP — Make a Request
4. Google Sheets — Add a Row

HTTP configuration

• URL: https://api.cryvis.com/v1/documents/invoice
• Method: POST
• Body type: Multipart/form-data
• Headers: Authorization: Bearer {{your Cryvis connection / key}}
• Fields: one field named file, type File, mapped from Drive’s binary data; set filename to the Drive filename so logs stay readable.

Parse JSON (success, data, meta). Map:

Attach an Error Handler → Break on the HTTP module for 402 / 401 / 422 so incomplete executions retry after you fix credits or the file. Details: Handle Cryvis API errors in Make.com.

Product page: Invoice OCR API.

Sample B: same Drive folder, non-standard PDF → custom

Suppose the folder also gets landlord “rent statements” that are not invoices. Create an extractor in Console with fields like property_address, period_start, period_end, amount_due, account_number. Cryvis gives you a slug.

HTTP module:

• URL: https://api.cryvis.com/v1/custom-extractors/rent-statement (your slug)
• Multipart: file = Drive binary

Map only the keys you defined. Schema design notes: Custom extractor schemas and Extract specific fields.

Product page: Custom Document Extraction.

Credits and multi-page PDFs

A 4-page invoice PDF costs 4 credits. A single JPEG of a passport page costs 1. Multi-file receipt uploads can batch into results[]—parse that shape carefully (Parse API JSON responses).

Trim scanned PDFs before upload if page 2–N are blank terms-and-conditions; you still pay per page.

Common mistakes

1. Calling a fictional /v1/ocr or /v1/pdf. Not available. Use document routes or custom extractors.
2. Sending a passport as file. Passport requires first_page and last_page (multipart field names).
3. Ignoring meta.validation. Soft validation can return HTTP 200 with warnings—still inspect them before posting to the ledger.
4. Hardcoding the API key in every scenario. Prefer one HTTP connection / shared variable and rotate keys (Bearer auth).

Pattern catalog next

For sources × endpoints × destinations (Gmail, Dropbox, Slack, Notion, Airtable), continue with Extract structured data from documents in Make.com.

Checklist

• Document type identified before you pick the URL
• Correct multipart field names for that endpoint
• Bearer token from Console API keys
• Binary mapped from Drive/Gmail (not a public Drive link string)
• Sheets/CRM maps use data.* (or results[].data.* for receipt batches)
• Error handler on the HTTP module

Start extracting

Create a key in the Console, pick Invoice or Custom, and wire the HTTP module once. Then clone the scenario for the next document type instead of inventing a second OCR product that Cryvis does not ship.