Upload a File to the Cryvis API from Make.com
Map Google Drive or Gmail binary attachments into Cryvis multipart uploads in Make.com—Buffer mapping, filenames, and MIME checks.
Cryvis extraction endpoints expect multipart file bytes, not Drive share URLs. In Make, that means a module that produces a Buffer, then an HTTP multipart field of type File pointed at that Buffer.
This post covers Drive and Gmail → Cryvis binary mapping. Pair with Send multipart form data for field names and Send PDF to OCR API for a full invoice scenario. Hub: Make.com + Cryvis.
Mental model
Watch / Email
|
v
Get file content ===> bundle includes binary (Buffer)
|
v
HTTP multipart field type = File
data = Buffer
filename = original name
|
v
Cryvis reads bytes (pdf / jpeg / png / webp)Supported MIME types: application/pdf, image/jpeg, image/png, image/webp. Credits: 1 per page (PDF) or 1 per image.
Google Drive
- Watch Files in a Folder (or Watch All Files + filter).
- Download a File — map File ID.
- In HTTP multipart:
- Field name: depends on endpoint (
file,first_page,front, …) - Type: File
- File: map the download module’s data/binary output
- File name: map
namefrom Drive so Cryvis logs and receiptfile_namestay useful
- Field name: depends on endpoint (
Do not map webViewLink or webContentLink into the File field. Cryvis will not fetch Google for you.
Gmail
- Watch Emails (filter label/query as needed).
- Iterate attachments (or use an attachment-aware module that lists them).
- Filter: MIME in
{application/pdf, image/jpeg, image/png, image/webp}. - If the attachment module only returns metadata, use the Gmail action that downloads the attachment to get binary.
- Map that binary into HTTP File; filename from attachment filename.
Gmail Watch
→ Iterator attachments
→ Filter MIME
→ (Download attachment if needed)
→ HTTP CryvisOneDrive / Dropbox
Same pattern: Watch → Download/Get file content → Buffer → HTTP File field. Always verify the download module’s output type is binary before blaming Cryvis for InvalidFile errors.
Multipart field names (quick)
| Endpoint | Binary field(s) |
|---|---|
| invoice, receipt, pan, custom | file |
| aadhaar | file (1–2) |
| passport | first_page, last_page |
| indian-vehicle-rc | front, back |
| driver-license | file (+ text country) |
Full table: Send multipart form data.
Filename and content type
Make usually sets Content-Disposition filename from the File name you provide. Keep extensions accurate (.pdf, .jpg). Mismatched extensions with wrong bytes still fail conversion server-side.
Large multi-page PDFs burn one credit per page—trim before upload when possible (credits).
Common failures
| Symptom | Likely cause |
|---|---|
| 400 / invalid file | Mapped URL string instead of Buffer |
| Empty extraction | Wrong file downloaded (0-byte or HTML error page) |
| Wrong document schema | Correct binary, wrong endpoint |
| 422 conversion | Corrupt PDF or unsupported MIME |
Debug with curl using the same bytes Make would send. Auth: Bearer authentication. Errors: Handle API errors.
Checklist
- Download/get-content step present
- HTTP field type is File, not Text
- Filename includes a real extension
- MIME filtered upstream
- Field name matches the Cryvis endpoint
Once binary mapping works for invoice file, reuse it for custom extractors and identity APIs—only the URL and field names change. REST overview: Connect REST API.