← Back to blog

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

  1. Watch Files in a Folder (or Watch All Files + filter).
  2. Download a File — map File ID.
  3. 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 name from Drive so Cryvis logs and receipt file_name stay useful

Do not map webViewLink or webContentLink into the File field. Cryvis will not fetch Google for you.

Gmail

  1. Watch Emails (filter label/query as needed).
  2. Iterate attachments (or use an attachment-aware module that lists them).
  3. Filter: MIME in {application/pdf, image/jpeg, image/png, image/webp}.
  4. If the attachment module only returns metadata, use the Gmail action that downloads the attachment to get binary.
  5. Map that binary into HTTP File; filename from attachment filename.
Gmail Watch
  → Iterator attachments
  → Filter MIME
  → (Download attachment if needed)
  → HTTP Cryvis

OneDrive / 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)

EndpointBinary field(s)
invoice, receipt, pan, customfile
aadhaarfile (1–2)
passportfirst_page, last_page
indian-vehicle-rcfront, back
driver-licensefile (+ 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

SymptomLikely cause
400 / invalid fileMapped URL string instead of Buffer
Empty extractionWrong file downloaded (0-byte or HTML error page)
Wrong document schemaCorrect binary, wrong endpoint
422 conversionCorrupt 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.