The same API, three different connection patterns
Retool, Bubble and Airtable solve the same broad problem — build an app or a workflow without writing a full backend — but each has its own way of connecting to an external API. This page covers the one thing that stays constant across all three: a single call to POST /extract that turns a PDF, scan or photo into typed JSON, with the connection mechanics for each platform covered side by side further down.
If you're only using one of these three, the internal tools API page covers the same ground with more general framing; this page exists for teams comparing platforms, or using more than one at once.
It's a genuinely common situation — a team standardizing on one internal-tool platform for new builds while a legacy tool on another platform keeps running, or a growing team where different people have picked different app builders for their own projects. Knowing the underlying API behaves identically everywhere removes one variable from that kind of platform decision.
What the API returns for a PDF, scan or photo
POST /extract accepts a document and returns typed fields, line items when the document has a table, and a confidence score per field — the printed total checked against the sum of its own line items before the result comes back. The response shape is identical no matter which platform sent the request.
The response also includes the document type and, where printed, identifying details like a vendor or merchant name, so a downstream table in any of the three platforms can group and display results without a separate lookup step.
Nothing about the response depends on how the document arrived at the API either — a file uploaded through a Retool File Dropzone, a Bubble file input, or an Airtable attachment field all resolve to the same base64 payload the endpoint expects, so the platform-specific work is entirely in getting the file to the call, not in anything about the call itself.
Where a DIY PDF parser breaks inside an app builder
A generic PDF-text library, called from a Bubble backend workflow or an Airtable script, returns a block of raw text with no concept of fields — turning that into usable data means writing and maintaining pattern-matching logic inside the app builder itself, which is both awkward to do in a low-code environment and fragile the moment a document format changes.
What each platform actually needs is an endpoint that already returns typed data, so the app builder's own strength — binding a value to a UI component — is all that's left to do, covered per-platform in the comparison section below.
This gap tends to surface at a specific, predictable moment: the first document that isn't a perfectly clean digital export. A pattern-matching script tuned against a handful of test PDFs usually handles those fine; a scanned document, a slightly rotated photo, or a vendor whose layout differs from the ones tested is where a homegrown parser inside any of the three platforms tends to need its first emergency fix.
Field-level validation on every document
Every document — the first one and the thousandth — gets the same treatment: line items or transactions summed and checked against the printed total or balance before the result is returned. This is what lets an internal tool trust a value with the same confidence regardless of how it was bound into the UI, rather than treating every document-sourced figure as inherently uncertain.
Pricing that fits a low, unpredictable internal-tool volume
The flat €0.035 per page holds at any scale, with no minimum monthly commitment. For an internal tool whose usage might be five documents one week and fifty the next — inherently unpredictable, and different for every team — this removes a real budgeting question: this month's usage costs exactly what last month's did per page, with nothing to renegotiate as usage rises or falls.
Full mechanics are on the pricing page; the rate quoted there is the same at ten pages a month and at ten thousand.
Real throughput numbers
| Pattern | Typical response time |
|---|---|
| Single document, called from a button click | A few seconds |
| A small batch (~20 documents) looped by a script | Under a minute |
| A larger batch (~200 documents) with modest concurrency | A few minutes |
For the typical internal-tool pattern — one document processed per user action — the single-document figure is what matters: fast enough that the person uploading waits on screen for the result rather than needing any kind of background job.
Retool, Bubble and Airtable, side by side
| Platform | Connection method | Binding pattern |
|---|---|---|
| Retool | REST API resource + query | Bind query result to a table or form component |
| Bubble | API Connector plugin | Use response as dynamic data in a workflow step |
| Airtable | Scripting app or Automation script | Write fields directly back to a record |
Step-by-step instructions for each platform, including the exact request setup, are in the guide how to add document extraction to a Retool or Bubble app.
A worked example: 300 PDFs a month across two tools
A small operations team runs two internal tools — a Retool app for vendor invoice approval and an Airtable base tracking receipts — that together process roughly 300 documents a month, averaging two pages each:
| Volume | Monthly cost | Annual cost |
|---|---|---|
| 600 pages/month across both tools | €21 | €252 |
€252 a year, split across two internal tools, is a rounding error against the time it would take to build and maintain a custom PDF parser inside either platform — and it's the line item that lets both tools show accurate data from day one instead of a rougher, hand-typed version.
Notably, neither tool needed its own separate extraction setup — the same API key and the same flat rate cover both, with usage simply summing across whichever platform generated the call. A team adding a third internal tool later, on either of the same two platforms or a new one, extends this exact arrangement without renegotiating anything.
PDF, scan, photo — one endpoint for all three
Format is detected automatically on every call, so none of the three platforms need to pre-sort a clean digital PDF export from a rougher phone photo before sending it — the API handles both through the same endpoint and reports what it received. This matters specifically for an internal tool, where whoever is uploading a document rarely controls its original quality.
Why quality doesn't change with which platform calls it
The extraction model has no awareness of Retool, Bubble or Airtable — it sees a file and returns a result, with accuracy depending entirely on the document itself. A team using more than one platform never has to account for one being "less accurate" than another; the underlying pipeline and confidence logic are identical regardless of the caller.
This is worth stating explicitly because it's a reasonable thing to wonder about — different platforms handle file encoding and upload slightly differently, and it's fair to ask whether that affects the document that actually reaches the API. It doesn't: as long as the file bytes arrive intact, the extraction result is identical regardless of which platform packaged and sent them.
Versus a generic PDF-parsing library
A generic PDF-text library — called from an Airtable script or a Bubble backend workflow — returns raw text with page and position information, not typed fields. Turning that into a total, a vendor name or a table of line items means writing pattern-matching logic inside the app builder itself, which is both harder to maintain in a low-code environment and fragile against any document format the library's original author didn't anticipate.
This distinction matters more once more than one platform is involved, since a pattern-matching approach built for one app builder's scripting environment rarely transfers cleanly to another's — a Bubble backend workflow's regex logic doesn't simply copy over into an Airtable script. A typed API response, by contrast, is just JSON, equally usable from any of the three.
The one thing that's identical across all three platforms
Regardless of which app builder you're in, the request itself never changes — same endpoint, same headers, same request body shape. Only the mechanism for making that HTTP call differs by platform, which is why switching platforms, or using more than one, never requires re-learning the API itself.
Getting a file back, not just JSON
The same call can return XLSX or CSV alongside or instead of JSON, useful when an internal tool needs to hand a working file to someone — a finance lead who wants a spreadsheet, not a data table — rather than display structured data on screen.
This is a small but genuinely useful option across all three platforms — Retool, Bubble and Airtable can each trigger a file download from a workflow step, so a request for "can you export this as a spreadsheet" doesn't require a separate export feature built from scratch.
Keeping an eye on accuracy as usage grows
At a handful of documents a week, a team simply notices if something looks off. As usage grows across more than one internal tool, tracking the share of documents flagged with low confidence becomes worth a brief monthly glance — a rising trend usually means a new document source or format has entered the mix, worth a quick look before it becomes a pattern nobody's tracking.
| Metric | Why it's worth watching |
|---|---|
| Low-confidence flag rate | Rising trend signals a new or unfamiliar document format |
| Monthly spend vs. document count | Should track linearly — a mismatch is worth investigating |
How a small team runs this day to day
Once live, ownership tends to split into two light habits: whoever set up the integration checks flagged, low-confidence records occasionally — typically a handful a week — and someone glances at the monthly usage figures described above. Neither is a real workload; a well-configured integration at internal-tool scale rarely needs more than a few minutes of attention a month once it's stable.
Where ownership tends to get murky is exactly the multi-platform case this page is written for — if a Retool tool and an Airtable base both call the same API, it's worth explicitly naming who checks each one's review queue, rather than assuming the other person is covering it. A brief shared note listing which tool belongs to whom avoids both tools quietly going unmonitored at once.
Who this is built for
Teams comparing Retool, Bubble and Airtable
Wanting to know the document-extraction story is identical regardless of which platform they choose.
Teams using more than one of these platforms at once
Where a single API needs to work the same way across every tool in their stack.
Citizen developers who care about PDF and scan quality specifically
Since documents in a real internal tool rarely arrive as clean digital exports.
Small teams wanting one vendor relationship, not three
A single API key and pricing model across every app builder in use.
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
Run a real document through /extractand check the output against what you'd enter by hand. A free plan account uses the exact same accuracy as a paid one, against a smaller monthly allowance.
Whichever of the three platforms you're building in, the same key and the same call work unchanged — test once, then reuse that same integration knowledge for any other tool you build later, on the same platform or a different one.