Make Integration — Document Extraction in a Scenario

What you need

Less than Zapier requires, which is the point. The HTTP module is part of Make itself rather than a premium add-on, so the blocker is your FlowParse page balance rather than your automation platform's plan tier.

The shape of the scenario

Every document scenario follows the same spine. What changes between one built on email and one built on a watched folder is only the first module.

flowparse.io

Configuring the HTTP module

Add an HTTP → Make a request module and fill it in as below. The single most important setting is Parse response: switch it on and Make turns the JSON reply into mappable fields automatically, so every extracted value appears in the field picker of later modules. Leave it off and you get a raw string you then have to parse yourself.

Why Make makes this easier

Our API takes the document as a base64 string. In most automation tools this is the step that stalls a first attempt, because the trigger hands you a binary file or a URL and the API wants text. Make solves it with a built-in function: wrap the file data in `toBase64()` inside the request body and you are done — no extra module, no code step, no separate plan tier.

The one thing to get right is which field you wrap. Modules that download a file expose the binary as `data` and the name as `fileName`, so `{{toBase64(1.data)}}` refers to the file content from module 1. If your trigger only gives you a URL, add an HTTP → Get a file module first to download it, then base64-encode that module's output instead.

{
  "file": "{{toBase64(1.data)}}",
  "filename": "{{1.fileName}}"
}

What you get back

With Parse response switched on, every field below becomes mappable in later modules. The envelope is always `{ type, pages, billedPages, data }`, and `type` tells you what the document turned out to be — so a single scenario can accept a mixed inbox of invoices, receipts and statements without you routing by file name.

{
  "type": "invoice",
  "pages": 1,
  "billedPages": 1,
  "data": {
    "type": "invoice",
    "data": {
      "supplier_name": "Northwind Supplies Ltd",
      "invoice_number": "INV-4417",
      "invoice_date": "2026-07-14",
      "currency": "EUR",
      "subtotal": 1840.00,
      "tax_amount": 368.00,
      "total": 2208.00
    }
  }
}

Splitting clean extractions from the rest

This is where Make earns its place. Add a second HTTP module calling `/api/v1/validate` — it is free and returns a 0–100 score with a grade — then add a Router with two paths: one filtered to good grades that writes straight to your destination, and one for everything else that posts to Slack or creates a review task.

Drawing that split visually matters more than it sounds, because the alternative is an automation that silently writes wrong numbers into your books. For bank statements the validator checks the extracted transactions against the statement's own opening and closing balances, so an incomplete extraction fails loudly instead of looking plausible. The rules are documented on the validation engine.

flowparse.io

Example — invoices into Google Sheets

A good first scenario because you see it working immediately. Watch a Gmail label for attachments, base64-encode, POST to extract, then add Google Sheets → Add a Row and map supplier, invoice number, date, subtotal, tax and total into columns.

Add two extra columns that nobody thinks of at the time and everybody wants later: `billedPages` and the validation grade. When somebody questions a figure months afterwards, the answer is in the sheet rather than in a support conversation.

flowparse.io

Example — statements into ledger files

For bank statements a spreadsheet is often a staging post rather than the destination. Add a third HTTP module calling `/api/v1/export` with the extracted data and a format such as `xlsx`, `qbo` or `xero`; the response carries the finished file base64-encoded, which Make can decode and upload to Drive or attach to an email.

Be clear about what this does: it produces exactly the file your accounting software imports, removing the retyping step. It does not sign into QuickBooks or Xero for you. See PDF to QBO and bank statement to Xero for what those files contain.

flowparse.io

Handling a folder or a multi-attachment email

An email with eleven invoices attached, or a folder dropped at month end, is the normal case rather than the exception. Make's Iterator turns a bundle of attachments into separate items so each one flows through the extraction module on its own — which is what you want, because per-document calls are independently retryable and one corrupt file cannot fail the batch.

If the goal is a single consolidated workbook rather than a row per document, collect the extracted results with an Array aggregator and send them to `/api/v1/merge`, which consolidates up to 100 documents into one Excel file. That is the scenario equivalent of Smart Merge, and previews are free so you can check the column layout before spending anything.

flowparse.io

Error handling that does not lose documents

Make lets you attach an error handler route to any module, which is better than a platform that simply stops. Attach one to the extraction module and decide per status code what should happen, so a single bad scan never silently kills a month of processing.

What runs the meter

Make charges operations — roughly one per module execution — and FlowParse charges per page extracted. A four-module scenario consumes four operations per document, so a thousand invoices a month is around four thousand operations plus a thousand pages on our side.

Two things are free on our side and worth using freely: validation and export previews. They still consume a Make operation, but they cost nothing in pages, which means the quality gate is genuinely cheap insurance. Our plans and allowances are on the pricing page.

Scenarios people build

Receiving documents from your own app

Make's Custom webhook trigger gives you a URL that anything can POST to, which is the neatest way to connect a product you have built to an automation you do not want to build. Your application uploads the file to that URL, the scenario extracts and validates it, and the result comes back into your database through whichever module fits.

This is the pattern worth knowing about if you are tempted to write the integration yourself: the webhook belongs to Make, not to us — our API is a plain synchronous request and response. The webhook automation guide explains that architecture properly, including what to do when processing takes longer than your caller wants to wait.

What to know before scaling

Make handles volume better than most visual tools, but two ceilings matter. Operations are metered, so a scenario with many modules costs proportionally more per document — it is worth collapsing steps you do not need rather than leaving exploratory modules in a production scenario. And our API accepts documents up to 20 MB per request, so a very large scanned annual statement needs splitting or a different route such as batch processing.

The other practical note is scheduling. A scenario that polls every minute costs operations even when there is nothing to do. Match the interval to how quickly documents genuinely need processing — for most finance workflows every fifteen minutes is indistinguishable from instant, and considerably cheaper.

Keys, documents and who can see them

Your API key sits in the HTTP module's headers, so anybody who can open the scenario can read it. Use a dedicated key for automation — created and revoked at get an API key — so revoking it never breaks anything else you run.

The documents pass through Make's infrastructure on the way to us, which is worth weighing if the files are genuinely sensitive; self-hosted n8n is the answer when they must not leave your own network. On our side requests travel over HTTPS, uploaded files are processed to produce the response rather than kept as downloadable documents, and nothing is used to train models — see the security page.

When Make is the right choice

Make is the middle option and often the right one. Against Zapier: the HTTP module is not restricted to a premium tier, `toBase64()` removes the awkward step, and the visual router makes branching obvious rather than a stack of filters. Against n8n: Make is hosted, so there is nothing to run or update, and the learning curve is gentler.

Where Make loses is when documents must never leave your infrastructure, or when volume is high enough that per-operation pricing starts to matter more than convenience — both point to n8n. And if you have engineers, calling the document extraction API directly is less machinery than any visual platform.

Proving it works before it runs unattended

Use Run once with a real document rather than sample data, because sample data will not reveal whether your `toBase64()` mapping points at the right field. Open the module's output bundle and read the actual response — confirm `type` is what you expected and that the fields you plan to map are populated and typed correctly.

Then break it deliberately. Send a deliberately unreadable scan and confirm the 422 takes your error route rather than stopping the scenario. Send a document whose totals do not add up and confirm the router sends it for review. Validation is free, so this costs only operations. Turn on scenario error notifications before you leave it running.

Running it well

Always validate and always route on the result — an unattended scenario without a quality gate is a fast way to get bad data into your books. Store the raw response somewhere queryable so a questioned number can be traced back to what the document actually said, rather than reconstructed from memory.

Use a dedicated key per scenario so usage is attributable in the dashboard and revocation is surgical. Keep an eye on the 422 rate: a rising share of unreadable documents is almost always an upstream change, such as a client switching from downloading statements to photographing them, and it is much cheaper to fix at the source than downstream.

flowparse.io

Where to go from here

The full endpoint reference is in the API docs. For document-specific schemas see the invoice parsing API, the receipt OCR API and the bank statement API; for spreadsheet output see the PDF to Excel API. To compare platforms, see Zapier and n8n, or browse all integrations.

flowparse.io

Frequently asked questions

Related