What you can automate with Zapier
Zapier connects apps with trigger-and-action workflows called Zaps, and it is the fastest way to get document extraction running without an engineering team. A typical Zap watches Gmail for invoices, sends each attachment to FlowParse, and appends the extracted supplier, date, total and tax to a Google Sheet — built in an afternoon by the person who owns the process rather than by a developer.
The honest starting point: FlowParse does not have a native app in the Zapier directory yet. You connect through Webhooks by Zapier, Zapier's own step for calling any REST API. That is a real and fully supported route — it is how most APIs get used on Zapier — but it means you paste a URL and a JSON body rather than picking fields from a dropdown. The rest of this page is exactly what to paste.
What you get at the end is the same extraction the document extraction API provides: classified document type, typed fields, line items or transactions, and an optional quality score you can branch on before anything reaches your books.
What you need first
Two prerequisites, and one of them costs money on Zapier's side rather than ours. Webhooks by Zapier is a premium app, which Zapier restricts to paid plans — as published on Zapier's own pricing page, that means the Professional plan or higher. On the Free plan the webhook step is not available, so a Zap built this way cannot run. That is Zapier's rule and there is no way around it from our end; if you are on Free, the Make or n8n routes are cheaper for exactly this reason.
| Requirement | Where it comes from | Cost |
|---|---|---|
| Zapier plan with premium apps | Zapier Professional or higher | Zapier's pricing |
| Webhooks by Zapier | Built into Zapier, premium app | Included with the plan above |
| FlowParse API key | Get an API key | Free to create |
| A page balance | Any paid FlowParse plan or a top-up | See pricing |
The shape of the Zap
Every document Zap has the same four steps regardless of where the files come from. The only part that changes between building one for Gmail and one for Dropbox is the trigger.
1. Trigger
New attachment in Gmail, new file in Google Drive or Dropbox, or a form submission.
2. Encode
Get the file as base64 — most Zapier triggers can output a file object you can pass straight through.
3. Webhook POST
Webhooks by Zapier → Custom Request to /api/v1/extract with your bearer key.
4. Use the fields
Map the returned JSON into Sheets, Airtable, Xero, QuickBooks, Slack or an email.
Setting up the webhook step
In the Zap editor, add an action step and choose Webhooks by Zapier, then the Custom Request event. Custom Request is the one to pick rather than plain POST, because it lets you set the Authorization header, which the simpler POST action does not expose cleanly.
Fill in the fields exactly as below. The `file` value should be the base64 content of the document from your trigger step — in Gmail that is usually the attachment field, and Zapier will offer it in the field picker.
| Field | Value |
|---|---|
| Method | POST |
| URL | https://flowparse.io/api/v1/extract |
| Data Pass-Through? | no |
| Data | {"file": "BASE64_FROM_TRIGGER", "filename": "invoice.pdf"} |
| Unflatten | no |
| Headers | Authorization: Bearer pf_live_xxx · Content-Type: application/json |
What comes back, and how to use it
Zapier will show you the response after a test run, and every field in it becomes available to later steps. The envelope is always `{ type, pages, billedPages, data }`, and the inner object depends on what the document turned out to be — which the `type` field tells you, so you never have to sniff the file yourself.
{
"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
}
}
}Example — invoices into a Google Sheet
The most common build, and a good first one because you can see it working immediately. Trigger on a new Gmail attachment with a label such as `invoices`, run the webhook step, then add a Google Sheets → Create Spreadsheet Row action and map the returned fields into columns.
One tip that saves a lot of confusion later: add a column for `billedPages` and one for the extraction date. When somebody asks in three months why the page count on the invoice looks off, you will have the answer in the sheet rather than in a support ticket.
Example — statements into accounting software
For bank statements the more useful destination is your ledger rather than a sheet. Add a second webhook step calling `/api/v1/export` with the extracted data and a format such as `xlsx`, `qbo` or `xero`, and the response carries the finished file base64-encoded — which Zapier can then upload to Drive, attach to an email or push into a storage app.
It is worth knowing what this does and does not do. It produces exactly the file your accounting software imports, which removes the retyping step; it does not log into QuickBooks or Xero on your behalf. See PDF to QBO and bank statement to Xero for what those files contain.
Adding a validation step before anything is trusted
An unattended Zap will happily write a wrong number into your books forever, which is why the most valuable step to add is the cheapest one. Insert a second webhook call to `/api/v1/validate` with the extracted data. It is free, it returns a 0–100 score and a grade, and for bank statements it checks the extracted transactions against the statement's own opening and closing balance.
Then add a Zapier Filter step: continue only if the grade is A or B, and send anything else to a Slack channel or an email for a human to look at. That single filter is the difference between an automation you trust and one you have to spot-check. The rules behind the score are documented on the validation engine.
The one genuinely fiddly part
Our API takes the document as a base64 string in the `file` field. Most Zapier file fields hand you a URL or a file object rather than base64, and this is where most first attempts stall — you get a `400` because the API received a link where it expected content.
Two reliable approaches. The first is to use a trigger that provides file content directly, which several Zapier apps do; the field picker will show it and you map it straight into `file`. The second, when the trigger only gives you a URL, is to add a Code by Zapier step that fetches the URL and returns the base64 — a few lines of JavaScript, and Code by Zapier is available on the same paid plans as Webhooks. If neither is available on your plan, Make handles this more gracefully with a built-in `toBase64()` function.
What Zapier will show you when something fails
Zapier surfaces the HTTP status and body on a failed step, so the codes map directly onto what to fix. Turn on Zap error notifications — the default is easy to miss, and a silently paused Zap is how a month of invoices goes unprocessed.
| Status | What it means | Fix in the Zap |
|---|---|---|
| 400 | The file field was not valid base64 | Check you mapped file content, not a URL |
| 401 | Key missing or wrong | Re-check the Authorization header spelling and value |
| 422 | Document unreadable (not billed) | Filter these to a review channel; ask for a better scan |
| 429 | Page budget exhausted | Top up; Zapier will retry held tasks |
| 503 | Temporary | Zapier's automatic retry usually clears it |
What this costs on both sides
There are two meters running and it is worth understanding both before you build. Zapier charges you per task — roughly, per step that runs — so a four-step Zap consumes four tasks per document. FlowParse charges per page extracted from your plan's allowance, with validation and export previews free.
That combination has a practical consequence: adding the free validation call costs nothing with us but does consume a Zapier task. It is still worth it, but if you are near a Zapier task limit, that is the trade-off you are making. Our plans and page allowances are on the pricing page.
| Step | Zapier cost | FlowParse cost |
|---|---|---|
| Trigger (new email/file) | 1 task | — |
| Webhook → /api/v1/extract | 1 task | Per page |
| Webhook → /api/v1/validate | 1 task | Free |
| Filter on grade | Free in Zapier | — |
| Write to Sheets / Drive | 1 task | — |
Zaps people actually build
Mailbox to ledger
Supplier invoices arriving by email become validated rows in a sheet or a ledger import file.
Expense receipts
Employees forward receipt photos to an address; extracted totals land in an expense tracker.
Client onboarding
Bank statements dropped into a shared folder come back as clean Excel workbooks.
Alerting
Any invoice over a threshold posts to Slack for approval before it is recorded.
Where the documents come from
The trigger is the part you will change most often, and Zapier's breadth here is the main reason to use it over writing code. Any app that can produce a file can start the workflow, which means you rarely have to change how documents arrive — you automate what people already do rather than asking them to do something new.
In practice a dedicated mailbox or a watched folder beats asking colleagues to adopt a new upload form, because it requires no behaviour change at all. If your documents arrive through a channel Zapier does not cover, n8n can be self-hosted next to your own systems and reach things a cloud platform cannot.
| Trigger app | Typical use | Gives file content? |
|---|---|---|
| Gmail / Outlook | Invoices arriving by email | Yes, as attachment |
| Google Drive / Dropbox | A watched 'to process' folder | Usually a URL — may need a Code step |
| Typeform / Google Forms | Customer or employee uploads | URL |
| Slack | Documents shared in a channel | URL |
| Schedule | Poll a folder on a timer | Depends on the paired app |
What to know before you scale it up
Zapier is excellent at moderate volume and awkward at high volume. Tasks are metered, Zaps run sequentially per trigger event, and a large backlog processes slower than a purpose-built worker pool would. A practice handling a few hundred documents a month will be very happy; one handling several thousand a day will find the task cost and the throughput both start to argue for code.
The other limit is file size. Zapier's handling of large attachments is not unlimited, and our API accepts documents up to 20 MB per request. A 40 MB scanned annual statement will fail on both counts — split it, or handle those cases through batch processing in the browser instead of the automation.
Keeping the key and the documents safe
Your API key lives inside the Zap, so anyone who can edit that Zap can read it. On a shared Zapier account that is a real consideration — use a dedicated key for automation rather than the one you use elsewhere, so you can revoke it without breaking anything else. Keys are created and revoked at get an API key.
The documents themselves pass through Zapier's infrastructure on the way to us, which is worth knowing if you process anything genuinely sensitive. On our side requests travel over HTTPS, files are processed to produce the response rather than retained as downloadable documents, and nothing is used to train models — the security page has the detail.
When Zapier is not the right tool
Zapier's strength is breadth of triggers and a genuinely gentle learning curve. Its weaknesses for this particular job are that webhooks require a paid plan, base64 handling needs a workaround, and per-task pricing adds up when every document costs four tasks.
Make handles this workflow more comfortably — the HTTP module is available on lower tiers and it has a built-in base64 function — and its pricing model suits multi-step scenarios better. n8n is the choice when you want to self-host, keep documents inside your own network, or run high volume without per-task costs. And if you have engineers, calling the document extraction API directly is less machinery than any of them.
Getting it right before it runs unattended
Build the Zap with a real document rather than Zapier's sample data, because sample data will not tell you whether your base64 mapping is correct. Run the test, look at the actual response body, and confirm the fields you expect are populated and typed the way you assumed.
Then test the failure paths deliberately: send a deliberately unreadable scan and confirm the 422 goes where you want it rather than breaking the Zap, and check that your validation filter actually diverts a bad extraction. Validation calls are free, so this costs nothing but the Zapier tasks. Turn on error notifications before you walk away.
Running it well over time
Always include the validation step and always filter on it — an unattended pipeline without a quality gate is just a faster way to get bad data into your books. Keep the raw response in a column or a log somewhere, so that when a number is questioned you can show exactly what the document said rather than reconstructing it.
Use a dedicated API key per Zap so usage is attributable and revocation is surgical. Watch per-key usage in the dashboard for the spike that means something is looping. And revisit the Zap when your document mix changes — a new supplier who sends photos instead of PDFs will show up first as a rising share of 422s, which is a signal worth noticing early.
Where to go from here
For the endpoints in full, see the API docs. For document-specific detail, the invoice parsing API, the receipt OCR API and the bank statement API each cover their own schema, and the PDF to Excel API covers producing spreadsheets. To compare platforms, see Make and n8n, or browse all integrations.
Automate documents from your inbox
Wire FlowParse into a Zap and turn every invoice, receipt and statement that arrives into validated, structured data.
