Parse Cryvis API JSON Responses in Make.com

Cryvis wraps successful extractions in a consistent JSON envelope. Make must parse that JSON, then map the right branch: most endpoints expose data, while multi-file receipt (and other batch) calls expose results[].

Hub: Make.com + Cryvis. Field mapping next: Map API JSON fields.

Enable parsing

On HTTP — Make a Request, enable response parsing (Parse JSON / automatically detect JSON). Without it you only get a raw text string and cannot click fields in the mapper.

Success envelope (single document)

{
  "success": true,
  "data": { },
  "meta": {
    "document_type": "invoice",
    "request_id": "req_...",
    "validation": { }
  }
}

Custom extractors use the same shape; meta.document_type looks like custom:<slug> (docs).

HTTP
  → Filter success = true
  → Map data.* → Sheets
  → Map meta.request_id → Sheets

Batch envelope (results[])

When receipt (or other batch-capable) uploads send multiple files in one multipart request, the body looks like:

{
  "success": true,
  "results": [
    {
      "file_name": "receipt-001.jpg",
      "data": { },
      "meta": { }
    }
  ],
  "meta": {
    "request_id": "req_...",
    "document_type": "receipt"
  }
}

There is no top-level data in this mode. Map from each result:

HTTP (multiple file parts)
  → Iterator: results
       → Sheets row from results[].data
       → Store results[].file_name

Single-file receipt calls typically return the single-document envelope with data—inspect the live output once before building iterators. Product: Receipt API.

Invoice example paths

Invoice API. Tutorial: Send PDF to OCR API.

Error envelope (do not map as data)

{
  "success": false,
  "error": {
    "code": "CREDIT_ERROR",
    "message": "Insufficient credits."
  },
  "request_id": "req_..."
}

HTTP status is non-2xx; Make routes to the Error Handler. Map error.code / error.message inside that handler branch—not in the happy-path Sheets module. Handle API errors.

Soft validation on 200

Custom (and some document) responses can be success: true with meta.validation.warnings populated. Treat warnings as a Router branch, not as HTTP failure:

Router
  warnings empty → write ledger
  warnings present → Slack review + optional write

Make gotchas

1. Assuming data always exists after a multi-file receipt call.
2. Mapping results as text instead of iterating collections.
3. Ignoring success and writing empty rows when the module somehow continued.
4. Confusing invoice data.validation (inside extracted invoice) with meta.validation—check OpenAPI / live payload for the endpoint you call.

Checklist

• Parse response enabled
• Filter on success
• Single vs batch shape confirmed with a real run
• Iterator added for results[]
• meta.request_id stored for support

Auth header reminder: Bearer authentication. End-to-end REST: Connect REST API.