You're building an app, not an extraction pipeline
A citizen developer putting together an internal tool in Retool, Bubble or Airtable is usually solving a specific, small problem — an approval queue for vendor invoices, a receipt log for expense reports, a lightweight intake form that turns a PDF into rows in a table. Somewhere in that build, a document arrives and needs to become data: fields, line items, a total, a date. Building the thing that reads that document is not the app you set out to build — it's a detour into document understanding that most internal-tool builders have no interest in owning.
This page is about the API that removes that detour: one HTTP call, made from inside the action or workflow step your app builder already supports, returns the document as structured JSON — ready to write into a table, populate a form, or trigger the next step in your app's own logic.
What the API actually does
One endpoint, POST /extract, accepts a PDF, image or scan and returns a classified, structured, validated result — the document type, every field with its value, line items when the document has a table, and a confidence score per field. There is no setup step, no template to configure, and nothing to train on your specific document before the first real call.
This isn't the Zapier/Make/n8n angle
It's worth being explicit about a distinction this page deliberately draws, because the two are easy to conflate. Zapier, Make and n8n are automation-recipe platforms — a trigger fires on an event (a new email, a new file in a folder) and a chain of unattended steps runs in response. That pattern, including webhook design, retries and idempotency, is covered in full in the guide automate document extraction with webhooks.
This page is for a different persona and a different pattern: you're building an actual application — a UI, a data model, buttons a person clicks — in an app builder like Retool, Bubble or Airtable, and you want a single synchronous call inside your own action, not an external automation reacting to events on its own schedule. No webhook, no trigger, no unattended recipe — just a function call your app makes when a user does something.
Why a citizen developer shouldn't build this from scratch
A generic OCR service or an open-source model reads pixels and returns text — turning that text into typed fields, reconstructing a multi-row table, and producing a confidence signal per field is a real engineering project, not a weekend script, and it's exactly the kind of work an app builder's whole value proposition is meant to let you skip. Most citizen developers building an internal tool have neither the time nor the interest in becoming a document-parsing team on the side of whatever the actual tool was supposed to do.
A single API call that already does the hard part — classification, field extraction, table reconstruction, validation — keeps the build inside the no-code or low-code paradigm the whole tool is built in, rather than forcing a detour into custom backend code just to handle documents.
This matters more than it might first seem, because the detour rarely announces itself as one. A first test on a clean, hand-picked document looks solved in an afternoon; it's the second or third real document — a different vendor, a slightly blurry scan — that reveals how much work actually sits behind "read a document and turn it into data," usually after the decision to build it yourself has already been made.
The one call that matters
Everything on this page comes down to a single request. It's documented in full, with every parameter, in the API documentation— here's the shape you'll actually wire into an app builder's REST resource.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "vendor-invoice.pdf" }'
# → { "type":"invoice", "pages":2, "billedPages":2,
# "price": { "eur":0.07, "perPageEur":0.035, "complexity":"standard" },
# "data": { "type":"invoice", "data": { "vendor_name":"Acme Supplies",
# "invoice_number":"INV-4471", "total":842.50, "currency":"USD",
# "line_items":[ ... ] } } }What comes back
| Document type | What's returned |
|---|---|
| Invoice | Vendor, number, dates, currency, line items with quantity and unit price |
| Receipt | Merchant, date, total, tax when present, line items when legible |
| Bank statement | Every transaction with date, description, signed amount, running balance |
| General document | Whatever typed fields the document's own structure supports |
Every field arrives typed — a number as a number, a date as a date — so your app builder's table or form binding doesn't need a parsing step of its own before the value is usable.
Pricing that fits an internal tool's real volume
A flat €0.035 per page, at any volume, with no minimum commitment. An internal tool built for one team's use — a few documents a day, a burst around month-end — is exactly the shape of usage a flat per-page rate is designed for: no enterprise tier to unlock, no monthly plan to commit to before you know how much the tool will actually be used.
A free plan account gets full accuracy against a smaller monthly allowance, which for many internal tools is enough to run real usage without ever needing to upgrade.
Turnaround inside an app's request cycle
A single document typically returns in a few seconds — fast enough to call synchronously from a Retool query, a Bubble workflow step, or an Airtable script, with the user waiting on screen for the result rather than polling for a webhook later. This is the property that makes the app-builder pattern practical: the call fits inside the same request that already handles a button click or a form submission.
Retool: a REST API resource and a query
Add a REST API resource pointed at https://flowparse.io/api/v1 with your API key in the Authorization header, then create a query that calls POST /extract with the uploaded file's base64 content. Bind the query's result directly to a table or form component — Retool's own file upload widget already gives you the base64 payload the request needs, so no transformation step is required before the call.
Bubble: an API Connector call
Add the extraction endpoint as an API Connector call, configure the Authorization header with your key, and mark the response fields you care about so Bubble can use them as dynamic data in a workflow. A workflow action triggered on file upload — "When Input file's value is not empty" — is the typical pattern: the file goes to the API, the response populates a data type your app already defines.
Airtable: a scripting step or automation
Airtable's Scripting app, or a "Run a script" step inside an Automation, can fetch the extraction endpoint directly and write the typed fields back into a record — one script handles the whole round trip from an attached file to populated columns. For a base already tracking vendors or expenses, this turns an attachment field into structured data without leaving Airtable at all. See the Airtable integration page for the broader connection options beyond a single script.
A worked example: an internal invoice approval tool
A small ops team builds an internal Retool app for invoice approval: someone uploads a vendor invoice, the app extracts vendor, amount and due date, and routes it to the right approver based on amount. The extraction call is the first step in the app's own workflow, not a separate system to integrate with.
| Step | Result |
|---|---|
| Invoice uploaded, extraction called | 1.2 seconds, 2 pages, €0.07 |
| Fields bound to the approval form | Vendor, amount, due date populated automatically |
| Confidence check | All fields above 0.95 — no manual re-entry needed |
| Monthly cost at ~150 invoices | ~€10.50, well under the free plan allowance |
The whole build — resource, query, form binding, approval routing — took an afternoon, with no backend service to deploy or maintain beyond the Retool app itself.
Accuracy and the confidence signal
Field-level accuracy runs around 99% on standard documents, with a confidence score attached to every field rather than one signal for the whole document. For an internal tool, this is what lets you show a low-confidence field differently in your UI — a highlighted cell, a required-review badge — instead of treating every extracted value as equally trustworthy.
What kind of documents this handles
A digital PDF export, a scanned document, and a phone photo of a receipt all go through the same endpoint and come back in the same shape — relevant for an internal tool specifically because the person uploading a document is often not the person who created it, and rarely controls its quality. Format detection is automatic, so your app's upload step doesn't need to pre-sort anything.
Where a human still belongs in a small internal tool
Extraction removes the typing, not the judgment call on an unusual invoice or a receipt that looks off. Because every field carries its own confidence score, a small internal tool can implement review with almost no extra work — a conditional that shows an "approve" button only when every field clears a threshold, and a "needs review" state otherwise, is often the entire review workflow a small team needs.
Who this is built for
Citizen developers building an internal tool
In Retool, Bubble, Airtable or a similar app builder, needing document data inside their own UI and data model.
Small ops or finance teams
Automating a specific internal process — approvals, expense logs, intake forms — without a dedicated engineering project.
Engineers prototyping quickly
Who want a working document-handling feature today, not a multi-week extraction pipeline before the app is usable.
Teams migrating off manual data entry into a spreadsheet or base
Where someone currently retypes a document's fields into Airtable or a similar tool by hand.
Common objections, answered honestly
"My documents are too varied for an automated tool" is the most common objection, usually based on experience with an older, template-driven OCR tool tuned to a narrow set of layouts. A classification-first pipeline built across a broad range of real document formats, not a fixed template, is designed for exactly this variety — a document format the pipeline has never seen is handled the same way as a familiar one.
A second objection is cost uncertainty for a small, low-volume tool — worrying that any API pricing model assumes enterprise-scale usage. In practice, a flat per-page rate with no minimum means an internal tool used a handful of times a week costs a few cents a month, not a subscription sized for volume you don't have.
A third, quieter objection is a worry about lock-in — connecting an external API feels like a dependency a small internal tool shouldn't need. In practice, the response is plain JSON your app already owns once it arrives; nothing about switching extraction providers later would require rebuilding the table, form or workflow logic built around that response.
What happens if the internal tool outgrows "internal"
Nothing about the integration needs to change if usage grows — the same synchronous call that handles ten documents a week handles a thousand, since pricing and capacity are consumption-based rather than tied to a fixed infrastructure tier. If the tool eventually needs true batch processing — hundreds of documents at once rather than one per user action — that's the point to introduce concurrency on your side, covered in the guide how to add document extraction to a Retool or Bubble app.
This is a genuinely common trajectory — a tool built for one small team becomes useful enough that other teams want it, and volume grows well past what "internal" originally implied. Because the underlying call never changes, that growth is a scaling question, not a rebuild question: the same integration that served five users comfortably serves fifty.
Security and data handling
Uploads are encrypted with TLS from end to end.
Processing runs on infrastructure with SOC 2-aligned controls.
Original documents are deleted shortly after processing.
Nothing uploaded is ever used to train AI models.
Full details are on the security page.
Get your API key
Wire up a real document from inside your app builder and compare the result against what you'd type in by hand. A free plan account uses the exact same accuracy as a paid one, just against a smaller monthly allowance.