What "embedded" means here
Embedded, in this context, means the extraction capability disappears entirely into your own product — a user photographs a receipt inside your app, and the structured result appears inside your app's own expense line, with nothing in between that looks like a separate vendor step. This page covers that specific pattern in depth; the core API page covers the full field schema, pricing and general integration steps that apply either way.
White-label by default, not by request
Every response from the API is plain structured JSON — merchant fields, line items, totals — with nothing that identifies FlowParse as the vendor. There's no separate white-label tier or add-on to purchase, because there's no branding surfaced in the first place that would need removing. A standard free-plan account behaves identically to a large enterprise account on this point.
This is a deliberate design choice, not an oversight — plenty of API vendors treat white-labeling as a premium feature reserved for enterprise contracts, which pushes a smaller platform toward either paying for a tier it doesn't need yet or accepting visible branding it would rather not have. Making the default unbranded removes that tradeoff entirely, regardless of account size or contract value.
Why embedding beats a visible integration
A user submitting an expense receipt inside your product has one mental model of what's happening: they're using your product. Any visible seam in that experience — a redirect to a partner site, a "processed by [vendor]" watermark, a separate login for the extraction step — breaks that mental model and, in practice, generates support questions your team then has to field about a vendor your users were never meant to know existed. An invisible integration avoids that entirely: the receipt goes in, structured data comes out, and nothing in between needs explaining.
There's a product-trust dimension too. A platform that visibly outsources a core-feeling capability can read, to a skeptical enterprise buyer, as less mature than one where every part of the experience feels native. Whether or not that perception is fair, it's real, and it's a large part of why most platforms embedding a document-extraction API choose to do so completely invisibly rather than disclosing the vendor relationship in the product itself.
Three embedding patterns
Server-to-server, invisible to the client
Your backend calls the API directly after receiving an upload from your own app; your frontend never talks to FlowParse at all.
Client uploads, your backend proxies the call
A mobile or web client uploads to your own API, which forwards the document server-side — keeps your API key off the client entirely.
Async queue for batch or offline capture
A queued job processes a backlog of receipts (common for an overnight reimbursement run), reading results back once complete rather than waiting synchronously.
Why there's no hosted UI to redirect to
Some document-processing vendors offer a hosted capture or review page your users get redirected to — convenient to integrate quickly, but a visible seam that breaks the illusion of one unified product. This API is deliberately API-only: there's no hosted page, so nothing in the user experience needs explaining as "you'll be taken to our partner's site for this step."
Setting your own margin on top
Because the underlying cost is a known, flat €0.035 per page, building your own pricing on top of it — bundled into a plan tier, metered as a usage-based add-on, or absorbed as a cost of doing business — is a straightforward calculation rather than a moving target. The full mechanics of the flat rate are on the flat-rate pricing page.
What comes back, unbranded
{
"type": "receipt",
"data": {
"merchant_name": "Delta Coffee Roasters",
"total": 14.75,
"currency": "USD",
"line_items": [ { "description": "Latte", "quantity": 2, "unit_price": 5.25 } ]
},
"price": { "eur": 0.035 }
}Nothing here needs stripping or re-labeling before it reaches your own database or UI — it's already in the shape a product team would design if building this internally.
Mobile capture without a vendor SDK
A spend platform's mobile app almost always owns its own camera capture experience — the framing guides, the flash handling, the "retake photo" flow. None of that needs to come from FlowParse; your app captures the image however it already does, and simply uploads the resulting file to the extraction endpoint. There's no proprietary mobile SDK to integrate or keep updated.
Multi-tenant platforms and per-customer usage
A platform serving many customer companies from one codebase can attribute extraction cost per tenant simply by tagging or logging which customer each API call belongs to on your own side — the API itself doesn't need to know about your tenant structure at all, since every call is independent and billed identically regardless of which of your customers triggered it.
This is also the simplest way to build usage-based billing for the feature if you choose to expose it that way to your own customers — your backend already has the tenant context at the moment it makes the call, so cost attribution is a straightforward log entry rather than something that needs coordinating with the extraction vendor at all.
A worked embedding example
A spend-management platform serving 200 client companies embeds extraction behind its existing mobile receipt-capture screen. A user at Client Company A photographs a receipt; the app uploads it to the platform's own backend, which calls POST /extract, tags the result with Client Company A's tenant ID, and stores it. Client Company A never sees a FlowParse reference anywhere — to them, the platform simply "reads receipts."
Reseller economics: what margin looks like in practice
Most platforms embedding this capability price it one of three ways: folded invisibly into an existing plan tier (the most common approach, since the per-page cost at typical usage is small relative to a monthly subscription), metered as a visible usage-based add-on for high-volume accounts, or absorbed entirely as a cost of running the product with no separate line item at all. Which one fits depends mostly on how usage-sensitive your existing pricing already is — a platform already billing per-seat or per-transaction can usually fold this in without customers noticing a change; a platform on a flat unlimited-usage plan may prefer to absorb it or introduce a fair-use cap.
Whichever model you choose, the flat €0.035-per-page cost is small enough per document that it rarely needs to be the dominant factor in your own pricing decision — a typical single-page receipt costs a fraction of a cent, well below what most platforms already charge per user per month for the capability as a whole.
An embedding checklist
Confirm no FlowParse reference needs to appear anywhere in your UI or terms
Choose one of the three embedding patterns above and confirm it fits your architecture
Decide how (or whether) the per-page cost is reflected in your own pricing
Confirm per-tenant usage attribution if you're a multi-tenant platform
Test the full flow from your own capture UI through to a stored, structured result
How this differs from the core API page
The core API pagecovers the full field schema, the build-vs-buy cost comparison and the general integration steps — read that first if you haven't. This page exists specifically for the embedding and white-label questions a platform team asks once they've already decided to integrate and are planning how it fits invisibly into their own product surface.
Testing an embedded integration before launch
Because nothing in an embedded integration is visible to an end user, testing it thoroughly before launch matters more, not less, than a visible integration where a broken step would at least be obvious. The most reliable check is an end-to-end one: capture a real document through your own actual UI exactly as a user would, confirm it reaches the extraction endpoint, and confirm the structured result lands correctly in your own data model — not just a direct API call tested in isolation from a terminal.
It's also worth deliberately testing what a low-confidence or failed extraction looks like inside your own UI before launch, since that's the case most likely to have been overlooked if the happy path was the only thing tested during development.
Who embeds this specifically
Spend-management SaaS reselling the capability
As part of a broader product, without disclosing the underlying extraction vendor to their own customers.
Vertical SaaS adding expense tracking as a feature
A property-management or field-service platform adding a receipt-capture feature without becoming an OCR company.
Platforms serving many client companies from one codebase
Needing per-tenant usage attribution without per-tenant API keys or accounts.
Mobile-first expense apps building their own capture UX
Wanting extraction as a backend capability, not a bundled mobile SDK to integrate.
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 you upload is ever used to train AI models.
Full details are on the security page.
Get your API key
Try a real embedding pattern end to end — upload a receipt from your own backend and confirm the response carries nothing that identifies FlowParse. No credit card required to start.