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.
Visible integration vs. fully embedded, side by side
Put concretely, the two approaches diverge on almost every axis a product or support team would care about:
| Dimension | Visible integration | Fully embedded |
|---|---|---|
| What the end user sees | A vendor name, logo or redirect somewhere in the flow | Nothing — the feature reads as native to your product |
| Support ownership | Split between your team and the vendor's own support channel | Entirely yours; the vendor is invisible infrastructure |
| Perceived product maturity | Can read as less finished to a skeptical enterprise buyer | Reads as a single, cohesive product |
| Pricing flexibility | Often constrained by a vendor's own visible pricing page | Entirely up to you — nothing customer-facing to reconcile |
| Integration surface | Sometimes includes a hosted UI or redirect to manage | API-only, one endpoint, no UI to integrate or maintain |
None of this means a visible integration is always the wrong choice — a vendor marketplace or an app-store-style ecosystem sometimes genuinely benefits from disclosed, branded integrations that users can discover and compare. For a spend-management or expense platform specifically, though, where the extraction step is expected to simply be part of the product rather than a discoverable add-on, the embedded pattern is the one almost every team in this category converges on.
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.
Managing the vendor relationship invisibly
An embedded integration doesn't mean the vendor relationship disappears — it means it's managed entirely on your side, invisible to your customers. Billing, support, API key rotation and usage monitoring all happen through your own account and your own internal processes, with no customer-facing surface that would reveal the arrangement. A support ticket about a misread receipt is triaged by your own team first, the same as any other product bug, with FlowParse involved only if your own investigation determines the extraction itself was genuinely wrong.
This is a meaningfully different operating model from a visible integration, where a vendor might offer its own customer-facing support channel — here, that layer doesn't exist by design, which keeps the support experience consistent with the rest of your product but does mean your own team owns the full triage path.
In practice this triage path is usually a short first pass, not a deep investigation: most support tickets about a receipt turn out to be a capture-quality issue (a blurry photo, a receipt cut off at the edge) rather than an actual extraction error, and a quick look at the original image alongside the returned data resolves the large majority of them without ever needing to involve the vendor at all. Escalating to FlowParse is worth reserving for the smaller set of cases where the original image is genuinely clear and the extracted data still looks wrong.
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."
Six months later, the platform has 40,000 receipts flowing through this same invisible path every month, at a cost of roughly €1,400 — folded into the platform's existing per-seat pricing rather than shown as a separate line anywhere. None of the 200 client companies has ever asked who or what actually reads the receipts, because from their side, nothing about the experience prompts the question — which is precisely the outcome a fully embedded integration is meant to produce.
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.
Three pricing models, compared
Worked through side by side, the three approaches trade off simplicity against visible margin capture differently:
| Model | Best fit | Trade-off |
|---|---|---|
| Folded into an existing plan tier | Platforms already billing per-seat or per-transaction | Simplest for customers, but margin isn't a visible line item |
| Metered usage-based add-on | High-volume accounts, or platforms wanting visible usage pricing | Clear cost attribution, but adds a new billing line customers see |
| Absorbed as a cost of the product | Flat unlimited-usage plans, or early-stage platforms prioritising simplicity | No new pricing complexity, but no direct margin capture on the feature |
Most platforms don't need to commit permanently to one model at launch — folding the cost into an existing tier is the fastest way to ship the feature, with the option to introduce a metered add-on later if a specific high-volume customer segment justifies the added billing complexity. Switching from absorbed to metered is a much smaller change than the reverse, which is one reason most platforms start simple and add pricing granularity only once real usage data justifies it.
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.
A reasonable path through both pages: read the core API page first for the field schema, pricing and general integration approach, then come back here when you're specifically ready to plan how the integration disappears into your own product experience.
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.
Scaling an embedded integration as your platform grows
Nothing about the embedding pattern itself changes as a platform grows from its first customer to thousands — the same server-to-server call, the same unbranded response, the same per-tenant usage attribution, at any volume. What does grow in importance is the internal tooling around it: a usage-monitoring dashboard that made sense as a manual check at ten customers needs to become an automated alert at a thousand, and per-tenant cost visibility that was a nice-to-have early on becomes genuinely necessary once individual customer accounts represent meaningfully different usage patterns worth understanding separately.
This is the same operational maturity curve most embedded infrastructure dependencies follow — the technical integration is largely done early, and what matures over time is the visibility and tooling your own team builds around it, not the integration itself.
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.