Predictability as a feature, not a footnote
Most pricing pages describe a rate. This one describes a decision: FlowParse's API bills every page identically, on purpose, because the alternative — a rate that shifts with a document's complexity — pushes real estimation work onto every integrator who has to forecast a bill before they can commit to using the product. Treating "the rate is easy to predict" as a feature in its own right, not just an implementation detail of the billing system, is the whole idea here.
Concretely: €0.035 per page, for every one of the document types the API classifies and extracts — invoices, receipts, bank statements, financial reports, brokerage statements, résumé/CV documents — and for every plan, from a free trial account to the highest usage tier.
What this replaced, and why
Until a repricing on 2026-08-22, the API billed on a complexity-scaled model — a clean, short, digitally-generated document landed toward the bottom of a roughly €0.01-to-€0.15-per-page range, a dense, low-quality scan toward the top. That model was arguably "fairer" in the narrow sense that a harder document cost more to bill against — but it made the number an integrator needed for forecasting genuinely unknowable in advance, since a document's exact price only resolved after it was actually processed.
The flat rate trades that narrow fairness for something a high-volume integrator generally values more: a number that can be quoted, multiplied and trusted before a single document is sent. The cost model underneath the product didn't disappear — it still exists internally to understand margin — but it's no longer something a customer has to reason about or estimate to use the API responsibly.
What this feature doesn't change
Doesn't change what gets extracted
Pricing is entirely independent of the extraction feature set — the flat rate doesn't unlock or gate any field, document type or export format.
Doesn't apply to the site's own subscription plans
The website's monthly subscription pricing is a separate surface with its own allowance structure — this page describes only the metered API.
Doesn't include a negotiated enterprise discount
The published rate is the rate at any volume. A very large integrator gets the same number a first-time developer does.
The price object on every response
{
"type": "invoice",
"pages": 4,
"billedPages": 4,
"price": {
"eur": 0.14,
"perPageEur": 0.035,
"complexity": "standard"
},
"data": { ... }
}euris what this specific document cost — no separate invoice line to reconcile against, no delay before the true charge is known. It's available in the same response as the extracted data itself.
A document is charged once
/extract bills the pages it reads. Asking for a file back in the same call — "export": { "format": "xlsx" } — costs nothing extra, in any number of formats requested together. Calling /exporton its own, separately, bills per page, since that specific call is the one doing the work of converting data that wasn't extracted here.
For a budget model, this rule matters more than it might first appear — an integration that needs both a JSON payload for its own database and an Excel file for a client-facing download doesn't pay twice for the same document, as long as both are requested in the same extraction call.
How it works
Send a document to /extract
Any supported type — pricing is decided after page count, not document type.
Pages are counted from the document itself
Exactly as printed — no rounding, no per-document minimum beyond the actual page count.
The flat rate is applied
pages × €0.035, shown directly in the response's price object.
The charge deducts from your balance
Visible immediately via GET /usage, alongside this month's running total.
A batch of mixed document types, priced
A finance-automation pipeline runs a nightly batch of 40 invoices (average 2 pages), 15 bank statements (average 4 pages) and 5 financial reports (average 12 pages) through /extract.
| Document type | Count × avg. pages | Cost |
|---|---|---|
| Invoices | 40 × 2 = 80 pages | €2.80 |
| Bank statements | 15 × 4 = 60 pages | €2.10 |
| Financial reports | 5 × 12 = 60 pages | €2.10 |
| Batch total | 200 pages | €7.00 |
No separate calculation is needed per document type, and no complexity assumption changes the answer — three genuinely different kinds of documents, one arithmetic rule applied consistently across all of them.
Flat rate vs. per-seat vs. credits
| Model | What determines cost |
|---|---|
| Flat per-page (this feature) | Total pages processed — a number you know before sending anything |
| Per-seat licensing | Number of internal users, unrelated to actual document volume |
| Credit systems | Whatever exchange rate the vendor sets between a "credit" and a document — often opaque and inconsistent across document types |
Reconciling spend without estimating
Because every /extractresponse carries its own exact price, a finance or engineering team reconciling actual spend against a budget doesn't need to reverse-engineer a bill from a separate invoice — summing the price.eur field across a batch, or simply reading thisMonth.spendEur from GET /usage, gives an exact figure with no estimation step in either direction.
Why the rate itself is a stable contract
A pricing model that changes shape — a new tier introduced, a discount structure revised — is a quiet kind of breaking change for any integration that hardcoded assumptions about cost. Reading pricePerPageEurlive from every response, rather than hardcoding €0.035 as a constant in your own codebase, means an integration's cost forecasting stays correct automatically even if the published number is ever revised — the same defensive pattern as reading any other API contract from the response rather than assuming it.
Cases this is built to handle cleanly
A single very long document
A 60-page financial report bills for exactly 60 pages — no per-document cap or special-cased rate for unusually long files.
A batch mixing every supported document type
Invoices, statements and reports all bill under the same rule, so a mixed pipeline doesn't need per-type cost logic.
A document that fails to convert
Never billed at all — the flat rate only applies to a page that actually produced extracted data.
Requesting several export formats at once
Xlsx, CSV and JSON together, in the same /extract call, cost the same as one — the page was only read once.
Who this matters most for
High-volume integrators forecasting a real budget
One multiplication instead of a complexity-mix estimate that can only be confirmed after the fact.
Platforms reselling extraction as part of their own pricing
A stable, known input cost to build a margin on top of, without a variable underlying rate to track.
Finance teams reviewing a vendor's cost structure
A pricing model simple enough to audit in one sitting, with no hidden tier logic to reverse-engineer.
Engineering teams comparing vendors on cost alone
A directly comparable per-page figure, rather than a range that needs its own document-mix modeling first.
Testing the rate itself before committing to anything
A free plan account gets the same flat rate everyone else does, which means the cheapest way to confirm this feature works as described isn't to read this page more carefully — it's to get a key and run GET /usage plus a real document through /extract, and compare the numbers that come back against the claims made here. There's no separate "sandbox mode" with fake pricing to account for — the free plan bills the same flat rate a paid one does, just against a smaller monthly allowance, so what you see in testing is exactly what production billing looks like.
That matters specifically for a pricing feature, where the temptation for a vendor is to show one number in documentation and quietly apply a different one in practice. The defensive pattern from earlier in this page — reading pricePerPageEur live rather than trusting a static claim — works precisely because a free account can run that exact check before a single euro of real spend is committed.
How this contract is versioned over time
The price object's shape — eur, perPageEur, complexity, billedPages— is treated as a stable field contract, the same way the rest of the API's response schemas are. New fields can be added to that object over time without breaking an integration that only reads the fields it already knows about; existing fields keep their name, type and meaning.
The complexityfield is the clearest example of that discipline in practice — it's functionally inert now that every document bills identically, but it was kept in the response rather than removed, specifically so an integration built against the older complexity-scaled model didn't need an emergency code change the day the rate went flat. A pricing change should be knowable from the rate itself, not from a broken deploy.
Why token-based cloud AI pricing doesn't map cleanly here
A general-purpose AI service often prices by token count — a unit that depends on how much text a model happened to generate or process, which is genuinely difficult to predict before a call completes, since it depends on the specific content of each document and how a model chooses to respond to it. That's a reasonable pricing unit for an open-ended text-generation workload, but a poor fit for document extraction specifically, where the natural, known-in-advance unit is simply how many pages a PDF has.
Billing on pages rather than tokens sidesteps that unpredictability entirely — a document's page count is fixed metadata, readable before a single API call is made, which is exactly the property a forecast needs.
Rounding and precision, made explicit
€0.035 per page means a single page costs three and a half tenths of a cent — small enough that rounding behavior matters if you're reconciling totals down to the cent across a large batch. The eurfigure in each response is computed from the exact page count and the exact rate, then rounded to two decimal places for that single document's charge — the same rounding convention a human invoice would use, applied per document rather than accumulated across a batch and rounded once at the end.
For a very large monthly reconciliation, this means summing each document's own price.eurfield can differ by a cent or two from multiplying total pages by the rate directly, purely from rounding accumulation — a difference worth knowing about before treating either method as the more "correct" one. GET /usage's thisMonth.spendEuris the authoritative figure for actual billing, since it's computed the same way the account is actually charged.
Why a simple pricing model is a real engineering decision
It would have been straightforward to keep the older complexity-scaled model and simply document it more thoroughly — publish the exact rules for what pushed a document toward the top or bottom of the range. That approach was deliberately not taken. A rate an integrator has to reason through a rules document to predict is still, in practice, unpredictable at the point where it matters most: before a decision to build on top of it gets made.
Collapsing the model to one number was a product decision made specifically for the integrator doing exactly the kind of unit-economics analysis this cluster is about — not a simplification for its own sake, but one aimed at removing a genuine source of budgeting risk from an integration decision.
Get your API key
Run a real document through /extract and read the exact charge back in the response. See the full pricing overview for worked examples at real volume, or the cost calculator for an instant figure at your own expected page count. Neither requires a credit card — a free plan bills at the exact same flat rate described on this page, just against a smaller monthly allowance.
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.
The short version
One number, one unit, no tier to guess at. That's the entire feature — and its simplicity is exactly the point, not a placeholder for a more elaborate pricing model still to come.