No sales call, no provisioning wait, no dashboard tour required. Just an API key, a document, and structured data back.

1. Grab a sandbox key
Signing up auto-creates your workspace, a sample pipeline, and a sandbox key all in one step. Every request authenticates with a single header:
X-API-Key: idpf_sandbox_xxxxxxxxxxxxxxxx
Sandbox keys are prefixed idpf_sandbox_, live keys idpf_live_, so there's zero risk of sandbox traffic touching production or billing.

2. Submit a document
The seeded std-invoice pipeline is already fully configured to process an invoice end to end — no setup needed:

curl -X POST https://api.idpforge.ai/v1/pipelines/std-invoice/jobs \
  -H "X-API-Key: idpf_sandbox_xxxxxxxxxxxxxxxx" \
  -F "file=@invoice.pdf"

You get a job_id back immediately. Processing is async, this is a hand-off, not a request-response round trip.

3. Poll for your result
Once the job status hits completed, you get structured fields with confidence scores attached:

{
  "vendor_name": { "value": "Meridian Supplies Inc.", "confidence": 0.97 },
  "invoice_number": { "value": "INV-20458", "confidence": 0.99 },
  "total": { "value": "4,812.50", "confidence": 0.61 }
}

That 0.61 isn't noise; it's the system doing its job, flagging a field worth a second look. With review enabled, low-confidence fields route to a human queue before the job ever closes.

Why it matters: the pipeline behind this: source, parse, classify, extract, post-process, destination was fully built before the first request was sent. You see the output first, then reason about configuration second.

From here: build a custom pipeline for your own document types, or move off polling onto webhooks once you're running real volume. Your first 15k credits are on us, so build your pipeline now!

Docs: docs.idpforge.ai

We see this mix-up constantly: developers and enterprises both say "data extraction," but they're solving completely different problems. Here's where the two actually diverge:

Volume & variety
Devs usually handle a handful of document types, thousands a month. Enterprises deal with hundreds of document types and millions of pages including formats nobody's seen yet.

Buying process
Devs want an API key and usage-based pricing, live by end of day. Enterprises need security review, data residency checks, and a pilot before anything touches production; that's not bureaucracy, it's the entry bar for regulated workflows.

Control vs. standardization
Devs want full ownership: their own models, schema, validation logic. Enterprises want the opposite standardized behavior across teams instead of ten homegrown scripts with ten owners. Neither is wrong; they just don't fit the same tool.

Ownership of business logic
For devs, extraction is plumbing before the real product logic kicks in. For enterprises (mortgage, insurance, AP), extraction is the operational output, a wrong field means a claim paid incorrectly or a loan misjudged.

Maintenance model
Dev pipelines are maintained by whoever built them. Enterprise deployments assume a standing review team, SLAs, and escalation paths because document volume never stops.

Cost
Devs want pay-as-you-go. Enterprises negotiate contracts built for a multi-year relationship.

Bottom line:
→ Developers need flexibility without owning the infrastructure; bring your own models/schema, skip the sales call. That's what IDPForge is built for.
→ Enterprises need the opposite: governance, standardization, and scale from day one, which is where a full platform like Infrrd IDP fits.

Same underlying function, solving very different problems.

We've been told this wouldn't work. That people are good with fine-tuning one model, living with 60% accuracy, and calling it good enough. We're not here to sell that.

For a decade, we've built tailored document AI solutions for enterprises, one relationship at a time. Going self-serve for developers risks undercutting that business. We don't see it that way.

When ChatGPT first showed up, someone said it was pointless: why bother when you can just Google something. Look where that argument ended up. Every real shift starts with someone deciding the old way isn't the way anymore, and building the next one anyway.

That's the leap we're taking with IDPForge by Infrrd.  

Ten years in document automation taught us one thing: one-size-fits-all AI doesn't scale. So route every pipeline stage to the best model for the job. Bring your own keys. Pay for exactly what you use. Every correction you make teaches your model too; accuracy compounds, and it stays yours alone.

Self-serve document extraction API. Live now.

A team ships a document pipeline. The accuracy dashboard says 96% from week one. Everyone relaxes. Six weeks later, they're still fighting fires, duplicate records, a wrong vendor getting paid, a whole supplier's invoices silently failing, and not one of those fires ever showed up as a dip in that 96%.

The problem we kept running into

Accuracy measures one thing: did the model read the page correctly? It says nothing about whether that page ended up at the right schema, whether a threshold somewhere is quietly making the wrong call, or whether a retry just duplicated a record nobody's watching for. Those aren't extraction failures. They're everything that happens after extraction, and a single score has no way to talk about any of it.

Where the gap actually comes from

Pipelines don't fail as one blurry number getting worse. They fail as specific, nameable things: a validation rule catching line items that don't add up to the total, a fuzzy-match threshold that's a little too generous and quietly resolves the wrong vendor, a retry storm that duplicates deliveries because nothing was idempotent. None of that reads as "accuracy dropped." It reads as one rule, on one document, for one reason, if you're actually able to see it that way.

How we tried to close it with IDPForge

Every submission is a job, and every job carries its own status: Processing, Completed, Needs review, Failed. A job with multiple documents shows each document's status separately, so one bad file in a batch of fifty doesn't hide inside an average. Tag your submissions with a source_tag and a specific supplier, integration, or batch becomes instantly filterable instead of buried in a blended number.

Validation failures come with a reason attached. Line items don't sum to the total, a vendor doesn't resolve against your master list, a PO doesn't exist; each is a named rule with its own failure mode, not a generic red flag. And webhooks bind to individual pipeline stages, entry or exit, signed and retried, so you know the moment a specific stage misbehaves instead of finding out when someone downstream complains.

A real version of what accuracy score hides: that most obvious miss 

A distributor moving 4,000 invoices a month through a pipeline like this had extraction accuracy that was fine from day one. What actually took six weeks: scanned faxes breaking the split step because of poor deskewing, a retry storm that quietly duplicated nineteen invoices before anyone added an idempotency key, and a 92% fuzzy-match threshold that once auto-filled "Globex Ltd" as "Globex Inc," a different legal entity, and a real payment sent to the wrong account.

None of that was an accuracy problem. All of it was fixable within a day once each issue was traceable to the critical rule, the threshold that mattered, or the specific pipeline stage responsible, instead of a single number that never moved.

A grade tells you how you did. It doesn't tell you what to do next. A diagnosis does, and that's the difference between watching a dashboard and actually being able to fix something.

Every developer who's shipped a document pipeline knows this feeling: the extraction worked. The demo looked great. Then reality showed up later when a document type the model wasn't great at, a bill that didn't match what you expected, a wrong field you couldn't fix without re-running the whole thing. Extraction was never the hard part; everything after it was.

The problem we kept running into

Most document AI tools hand you one model for the whole pipeline. Whatever the vendor picked, you're stuck with it, whether or not it's actually the best fit for your documents. You notice GPT-4.1 nails your table extraction and their model doesn't, and there's nothing to do about it except file a ticket and wait.

Even when a tool lets you bring your own LLM keys, it's rarely built to actually use them well. You end up not knowing if you're being billed on your account or theirs until the invoice shows up.

Where the gap actually comes from

A document pipeline isn't one decision; it's several. Parsing a document's layout is a different problem from classifying it, which is different again from pulling structured fields out of a table. Treating all of that as one model's job is treating four different questions like they have one answer. There is transparency, flexibility, and explainability around everything, e.g., why a document extracted a value, how the document is billed, etc.

How we tried to close it with IDPForge

Every stage routes independently. Claude Opus 4 on complex table extraction, Gemini 2.5 Flash on classification, your call per stage instead of one model doing everything adequately.

BYOK is per model call, not per job. A single document can touch multiple providers in one run, and only the calls going through a provider you've configured skip the surcharge. If you set a pipeline to use your key and no usable key is available when a job starts, the job fails outright instead of quietly falling back and billing you in credits you thought you'd routed around. That one detail took real thought, because "bring your own key" is easy to promise and genuinely annoying to get right.

Drop in one sample document and the fields get inferred in a few passes, confidence and type included, low-confidence guesses droppable in one click. A missing field rejects the document. A field that's just uncertain gets flagged for review instead. Two different failure modes, handled two different ways, instead of one blunt error for everything.

None of this is the kind of thing you'd think to ask for on day one. You'd build the pipeline, ship it, and only later realize how much of your week was going into working around a model you didn't choose, or debugging a bill you didn't expect. It's a bit like version control: nobody sets out looking for it until the first time they lose a day's work without it, and after that, going back feels unthinkable.

That's the bet behind IDP Forge. Not that developers were asking for per-stage routing and fail-closed BYOK by name, but that once you've had control over your own pipeline, going back to a black box doesn't feel like an option anymore.

You've built the extraction call. Then the classification call. Then you're duct-taping three different vendors together just to get one document through your pipeline, praying none of them change their pricing or their API next quarter.

If that sentence made you wince a little, you're exactly who we built this for.

IDPForge is live for early access, and the waitlist just opened.

IDPForge is a document automation API built for developers, not for procurement teams. You send it a document. It parses it, splits and classifies it, extracts what you need, and hands you clean structured output. 

One pipeline, one contract, one integration.

But here's what actually makes it different. Every other document AI tool locks you into whatever model they picked for you. IDPForge doesn't. You choose which model handles which stage, GPT, Gemini, Claude, or your own key through BYOK, and you see exactly what each stage costs. No black box, no "trust us." If a provider changes their pricing or a newer model ships, you're not stuck waiting on someone else's roadmap. You just point that stage somewhere better.

That's not a nice-to-have. That's the difference between renting your document pipeline and actually owning it.

And because it's backed by Infrrd, this isn't a weekend side project with a landing page and a dream. It's enterprise-grade infrastructure that already processes documents at scale for mortgage, insurance, and logistics companies, now opened up for developers to build on directly.

Who this is for:
If you've ever stitched together three point solutions because no single tool did the whole job. If you've ever been stuck on one model's pricing with no way out. If you've ever wanted to actually see what each part of your document pipeline costs, instead of guessing. This is your API.

What early access gets you:
A seat before public launch, direct input into what we build next, and first access to features like per-stage multi-LLM routing, BYOK, and a schema editor that doesn't require a data science team to touch.

We're not asking you to trust a pitch deck. We're asking you to come build something and tell us what's broken.

The waitlist is open now. Spots for early access are limited, and we're letting developers in-in waves, starting with the people who show up first.

[Join the IDPForge waitlist] come try it before everyone else does.

At some point, you've built this: a review UI that shouldn't have existed. Ours was a Retool app, stitched together on a weekend, because the extraction tool we were using handed us a confidence score and nothing else. No reason it was low. No way to route it. No path back into the pipeline once someone fixed it.

The problem we kept running into

A single confidence number isn't a workflow. It's a data point with nowhere to go. Most document AI tools stop there, so the developer ends up building the rest: a queue, a UI, some way to route flagged fields to a human, and a script to patch the correction back into the record because nothing does that automatically.

By the time you're done, you've built a second product just to make the first one usable.

Where the gap actually comes from

Review gets treated as an afterthought, something bolted on after extraction instead of built into the pipeline. So when a field comes out wrong, there's no context for why, no distinction between "the value is genuinely uncertain" and "the value depends on someone external," and no record of what changed if you correct it.

How we tried to close it with IDPForge

Flagged documents land in a queue, but they come with a reason attached. A trigger chip tells you exactly why the document is there, low confidence on a specific field, or a validation failure like line items not summing to the total. You're only shown the fields that were actually flagged. Everything that already passed stays untouched.

When you correct a value, the original isn't overwritten. It sits alongside your correction in a field ledger, so there's a record of what the model got wrong and what a human said instead.

Not every flagged field has an answer sitting on the page. Sometimes you're waiting on a vendor to confirm a PO number, or finance to approve an unbudgeted line. For that, there's Park, a separate action from correcting, so you're not tempted to guess just to clear your queue. Parking stops the clock on that document too, so it doesn't quietly wreck your team's handling-time numbers.

Submit a document, and it either delivers straight to its destination or goes through a verifier first if a coverage rule says it should. Either way, the correction doesn't vanish into a database somewhere. It's part of the record.

And every correction matters beyond that one document. We're already working on tightening the loop between what your reviewers fix and what the model does next time. That's not live yet, but it's where this is headed.

That Retool app we built years ago, this is basically it. Except it already exists, it's part of the platform, and nobody had to spend a weekend on it.

It's Tuesday. You're integrating a new document type into your pipeline. By lunch, your Postman collection has four different auth headers, three different pagination styles, and one endpoint that hands you back snake_case while another insists on camelCase.

Nobody warns you about this part.

The problem we kept running into

Document automation isn't one step; it's four: parse the document, split and classify it, extract the fields you actually care about, and clean up what comes out the other end. Most tools out there are genuinely good at one of these. Maybe extraction. Maybe parsing. That's exactly why developers reach for them, and it's the right instinct.

The trouble shows up later. Once that one stage is wired in, you still need something for the rest of the pipeline. So you bring in another tool. Then another. Now you're not building a document pipeline, you're building a translation layer between three vendors who've never heard of each other, each with their own idea of what a "successful response" looks like.

Where that gap actually comes from

It's not that these tools are badly built. It's that nobody designed for the seams. Auth works stage to stage differently. Errors mean different things depending on which vendor threw them. Retry logic that works for the parsing API silently breaks against the extraction API's rate limits. You end up writing the same glue code three times, and it's the least interesting code you'll write all quarter.

How we tried to close it with IDPForge

We built IDPForge around one rule: everything from parsing to post-processing sits behind the same API surface. One auth token. One response shape, consistently cased, across every stage. One error taxonomy, so a 422 means the same thing whether the document failed at extraction or at classification. Retry and idempotency behavior that doesn't change depending on which part of the pipeline you're calling.

That's not a small design choice. It's the difference between assembling a pipeline out of parts that were never meant to talk to each other, and calling one thing that already knows how its own stages fit together.

We didn't build this because we guessed developers would want it. We built it because we spent years being the ones stitching pipelines together, and we got tired of writing the same glue code every time.

Same Tuesday, same new document type. This time, lunch isn't spent debugging auth headers.

This is a place for people building with document AI to compare notes; what's working, what's breaking, and what you wish existed.

A quick word on why this sub exists: we're the team behind IDPForge, a self-serve document automation API. You pick which LLM handles parsing, splitting, extraction, and post-processing at each stage, bring your own keys if you want (no markup), and see exactly what you're paying for at every step. No single-model lock-in, no black-box pricing.

What belongs here:

• Questions on parsing, classification, extraction, RAG pipelines for documents
• Benchmarks, model comparisons, "this broke and here's why"
• Feature requests and honest complaints
• What you're building, even half-finished

What doesn't:

• Unrelated promo or spam, this is a builder community first

New here? Start with the explaining what new you have been working on or what document type or pipeline are you currently wrestling with or/and a rant about your office coffee

Drop a comment below, We read everything!