What a high-volume integrator actually needs to know
A technical or financial evaluator scoping a document-extraction integration is rarely trying to answer "does this API work." That question gets answered in an afternoon with a free plan and a handful of real documents. The harder, slower-to-answer question is: what does this cost once it's running at the volume our product actually needs — 10,000 documents a month, or 500,000, or considerably more — and can that number be trusted before a contract gets signed.
That's a unit-economics question, not a feature question, and it deserves the same rigor a finance team would apply to any other per-unit cost line: a known rate, a known volume driver, and a formula simple enough that nobody has to trust a sales deck to get the forecast right.
Why per-page tiers make budgeting harder, not easier
A pricing model that scales cost with a document's "complexity" sounds fair in principle — a clean, single-page invoice shouldn't cost the same as a dense, forty-page financial report with a lower-quality scan. In practice, it pushes a genuinely hard estimation problem onto the integrator: before sending a batch of a million documents through a pipeline, how many of them will land in the cheap tier versus the expensive one? Answering that requires either running the actual documents through first — which defeats the point of forecasting in advance — or guessing, with a wide enough error bar that a budget built on it is closer to a range than a number.
A flat rate removes that estimation step entirely. Every page costs the same regardless of what the document looks like, so the only input a forecast needs is a volume figure your product team already has some handle on — expected documents per month, average pages per document — multiplied by one constant. It's a smaller, less interesting-sounding pricing model, and that is exactly why it's easier to build a reliable budget around.
What this page doesn't cover
Doesn't cover the monthly site-plan pricing
The dashboard's subscription plans (with a monthly page allowance) are a separate balance from the API's pay-per-page pricing described here — the API never spends your site-plan pages, and the site plan never gates API usage.
Doesn't set what you charge your own customers
This is FlowParse's cost to you, not a recommendation for your own resale or per-document pricing — that margin decision is entirely yours to make against your own product economics.
Doesn't cover extraction accuracy or field coverage
Pricing and accuracy are separate questions. See the API documentation and the feature pages in this cluster for what actually gets extracted and how reliably.
Where document APIs usually go wrong on pricing
Three patterns account for most of the budgeting frustration teams report when evaluating document-processing vendors: complexity-tiered rates that can't be known until after a document is processed, credit systems where a "credit" doesn't map cleanly to a page or a document, and per-seat licensing bolted onto a workload that has nothing to do with how many people use a dashboard. All three share the same underlying problem — the cost driver a vendor bills against isn't the cost driver that actually predicts your workload's volume.
For a high-volume integrator specifically, a page is the one unit that maps directly and transparently onto both sides of the transaction: it's exactly what the API processes, and it's a number your own pipeline already knows before a single call is made — a PDF's page count is metadata, not a guess.
The number itself
€0.035 per page— flat, for every document type the API supports (invoice, receipt, bank statement, financial report, brokerage statement, résumé/CV), on every plan, regardless of a document's length, layout, scan quality or how many fields it contains. There is no separate "complex document" multiplier and no volume discount tier to negotiate into — the number a solo developer's test call is billed at is the same number a million-page-a-month integration is billed at.
This is a deliberate simplification: FlowParse's API used to bill on a complexity-scaled range (roughly €0.01 to €0.15 per page, depending on what a document actually took to process), retired in a 2026-08-22 repricing specifically because a single, quotable number is easier for an integrator to build a reliable forecast around than a range that could only be pinned down after the fact.
The calls that carry a cost
Full endpoint documentation lives on the API docs page — the shape below is specifically what determines your bill.
curl -X POST https://flowparse.io/api/v1/extract \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "file": "JVBERi0xLjcK...", "filename": "invoice-batch-0412.pdf" }'
# → { "type":"invoice", "pages":4, "billedPages":4,
# "price": { "eur":0.14, "perPageEur":0.035, "complexity":"standard" },
# "data": { ... } }A 4-page document costs 4 × €0.035 = €0.14, shown directly in the response — nothing to compute on your side beyond reading the field back.
What the price object actually contains
| Field | What it tells you |
|---|---|
| eur | What this specific document was charged, in euros — pages × perPageEur. |
| perPageEur | The flat rate applied — always 0.035 under the current model, read live rather than hardcoded on your side. |
| complexity | Kept for backward compatibility with older integrations; always reads "standard" now that every document bills the same rate. |
| billedPages | The number of pages this call actually charged for — matches pages unless the document couldn't be converted, in which case it's 0. |
Reading eur back on every call, rather than recomputing it from a hardcoded rate constant on your side, is the more robust pattern — it stays correct even if the published rate is ever revised, without a code change on your end.
Worked examples at three volumes
| Monthly pages | Calculation | Monthly cost |
|---|---|---|
| 10,000 | 10,000 × €0.035 | €350 |
| 100,000 | 100,000 × €0.035 | €3,500 |
| 1,000,000 | 1,000,000 × €0.035 | €35,000 |
A hundred-thousand-page month scaling to a million pages costs exactly ten times as much, not some different multiple shaped by which tier the extra volume happens to fall into — the same property that makes it straightforward to model a growth scenario a year or two out, rather than only the volume you're processing today.
Monthly cost at common volume bands
| Documents / month (avg. 3 pages) | Pages / month | Monthly cost |
|---|---|---|
| 1,000 | 3,000 | €105 |
| 10,000 | 30,000 | €1,050 |
| 50,000 | 150,000 | €5,250 |
| 250,000 | 750,000 | €26,250 |
| 1,000,000 | 3,000,000 | €105,000 |
The average-pages-per-document assumption is the one number in this table worth replacing with your own — an invoice-heavy pipeline might average closer to 2 pages, a bank-statement pipeline closer to 4 or 5. The interactive calculator in this cluster lets you plug in your own figures directly.
What never costs a page
POST /validate — free on every plan, for testing your data contract before spending anything.
GET /usage — checking your balance and spend never costs a page, including for an account that's run out.
Accounting-format previews — checking how an extracted document will map to Xero, QuickBooks, DATEV and other targets before exporting.
A document the API can't convert — an unreadable or unsupported file is never billed, even though it consumed a call.
For a budget model, this matters beyond the obvious cost saving — it means a development and staging environment can run a realistic volume of contract tests without touching the production cost line at all.
Flat rate vs. the old tiered model vs. building it yourself
| Model | Forecasting a new volume | Ongoing cost surprises |
|---|---|---|
| FlowParse flat rate | Pages × €0.035 — one multiplication | None — the rate can't shift with what a document happens to contain |
| A complexity-tiered vendor | Requires estimating a complexity-tier mix in advance | A batch skewing toward the expensive tier changes the bill after the fact |
| Building your own OCR + review pipeline | Requires modeling infrastructure cost, engineering time and reviewer-hours separately | Accuracy regressions silently inflate reviewer time, which rarely gets tracked as a real cost |
The build-vs-buy comparison specifically — infrastructure, engineering time and reviewer-hours weighed against a flat per-page rate — gets its own detailed treatment in the cost-per-page economics guide in this cluster.
Common budgeting mistakes
Forecasting from documents instead of pages
A per-document estimate hides a real variable — a 1-page receipt and a 30-page financial report are both "one document" but cost very different amounts. Forecast from expected total pages, not document count alone.
Ignoring average page count drift as document mix changes
A pipeline that starts invoice-heavy and later adds bank statement reconciliation will see its average pages-per-document rise, which changes the monthly total even if document volume stays flat. Revisit the assumption periodically, not just once at launch.
Treating the site-plan and API balances as one pool
They're separate — a dashboard subscription's monthly page allowance never covers API calls, and API top-up pages never apply to the dashboard. Budgeting both against one shared number produces a wrong total.
Not accounting for retries during development
A malformed test call or an unsupported file never bills, but a genuinely successful extraction re-run to test downstream logic does. Budget a modest development-and-testing allowance separately from production forecast volume.
Topping up without a procurement cycle
curl -X POST https://flowparse.io/api/v1/topup \
-H "Authorization: Bearer pf_live_xxx" \
-H "Content-Type: application/json" \
-d '{ "eur": 500 }'
# → { "pagesAdded":14285, "currency":"eur",
# "pricePerPageEur":0.035, "newBalance":{ "pages":15097 } }€500 converts to exactly 14,285 pages at the flat rate — the same one-step arithmetic as everything else on this page. A top-up applies to your balance instantly, no procurement approval built into the payment path, which matters for a team whose actual document volume is genuinely uncertain until it's running in production.
Watching spend as volume grows
curl https://flowparse.io/api/v1/usage \
-H "Authorization: Bearer pf_live_xxx"
# → { "plan":"PRO", "pricePerPageEur":0.035,
# "balance": { "pages":812, "monthlyRemaining":712, "bonusPages":100 },
# "thisMonth": { "requests":143, "pages":288, "spendEur":8.18 } }thisMonth.spendEur is the actual number to reconcile against a forecast — checking it periodically against the pages-times-rate estimate from your planning is a quick sanity check that real volume is tracking what was modeled, not drifting silently.
A worked migration: replacing a per-seat vendor
A finance-automation platform previously paid a document vendor on a per-seat licensing model — a fixed monthly fee per user with access to the extraction dashboard, regardless of how many documents that team actually processed. As the platform's own customer base grew, document volume grew roughly in proportion to customer count, but the per-seat fee didn't move at all — the vendor relationship's cost stopped tracking the thing that actually drove the platform's own revenue.
| Metric | Old per-seat model | Flat per-page model |
|---|---|---|
| Cost driver | Number of internal users with dashboard access | Pages actually processed |
| Cost at 3× customer growth, same team size | Unchanged — team headcount didn't grow | Roughly 3× — tracks the revenue driver directly |
| Forecast for next year | Requires guessing future headcount | Requires estimating page volume, which maps to customer growth |
Neither model is universally "cheaper" in the abstract — the point of the comparison is that a per-page cost moves with the same variable that drives the integrator's own business, which makes it a genuinely easier number to build a multi-year forecast around.
From a pilot to millions of pages a month
A first integration typically starts with a free plan and a handful of real documents, confirming the response schema matches what a pipeline expects. From there, moving to production volume — 10x, 100x, or considerably more — requires no separate high-volume tier, no renegotiated contract and no change to the integration code itself. The same call and the same rate apply whether it's the first document processed or the ten-millionth.
That matters specifically for a budgeting exercise done early, before real volume is known — a forecast built on a conservative volume estimate doesn't need to be redone if actual usage comes in higher; it just plugs a bigger number into the same formula.
Who this is for
Technical evaluators scoping a build vs. buy decision
A known, flat rate to weigh directly against infrastructure and engineering-time estimates for an in-house pipeline.
Finance teams reviewing a vendor cost line
One number and one volume driver — easy to audit, easy to forecast, no tier structure to model separately.
Platforms billing their own customers per document
A predictable input cost that maps cleanly onto your own per-document or per-seat pricing model.
Engineering teams planning capacity ahead of a launch
A cost model that scales linearly with projected volume, without a separate high-volume negotiation to schedule first.
Why unpredictable pricing is its own integration risk
A vendor relationship that's technically reliable but financially unpredictable creates a real operational problem that has nothing to do with extraction accuracy — a finance team that can't trust a cost forecast will either over-provision budget as a buffer against uncertainty, or under-provision and get an unwelcome surprise mid-quarter. Both outcomes cost real money, just in different, harder-to-trace ways than the headline per-page rate itself.
A flat, published rate that the API demonstrably bills against — verifiable by reading it straight back from a live call rather than trusting a marketing page — removes that entire category of risk from an integration decision, independent of whatever the extraction quality itself turns out to be.
Get your API key
Grab a free API key and read pricePerPageEur straight back from GET /usage — no credit card required to confirm the number this page quotes.
Security and privacy
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 you upload is ever used to train AI models.
Full details are on the security page.