Build Your Data Extraction Pipeline with IDPForge in Minutes

What You'll Have By The End

By the time you finish this post, you'll have a sandbox key, a document submitted to a live pipeline, and structured fields with confidence scores read back, all without touching a UI.

That last part matters the most. IDPForge is built API-first, which means everything you can do in the dashboard, you can also do with curl. This post sticks to the terminal on purpose, so you can see exactly what's happening at each step without a screenshot standing in for the actual request and response.

Step 1: Get Your Sandbox Key

Signing up for IDPForge does three things automatically: it creates your workspace, seeds a sample pipeline, and mints a sandbox key. There's no manual setup required to get to your first request.

Your key lives under Admin → API keys, labeled Sandbox — default. It's shown once at creation, so copy it somewhere safe before navigating away.

Every request to IDPForge authenticates through a single header:

X-API-Key: idpf_sandbox_xxxxxxxxxxxxxxxx

No sessions, no cookies, no OAuth handshake. You attach the header, and the request is authenticated.

One detail worth noting: the key format is self-describing. A sandbox key looks like idpf_sandbox_..., and a live key looks like idpf_live_.... The environment is baked directly into the key string, so there's no separate flag or config setting to get wrong. Sandbox usage stays sandbox usage; it never touches billing, and it can't accidentally hit your production pipeline.

Step 2: Submit A Document

In IDPForge, a job is one submission to one pipeline. You're not configuring anything yet; the seeded pipeline, called std-invoice, already has everything it needs to process an invoice end to end.

To submit a document, POST it as multipart form data:

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

If you're working in Python, the same call looks like this using the SDK:

from idpforge import Client client = Client(api_key="idpf_sandbox_xxxxxxxxxxxxxxxx")job = client.pipelines.submit(    pipeline="std-invoice",    file="invoice.pdf")print(job.id)

The response comes back immediately, but it isn't the extracted data. It's a job ID:

{  "job_id": "job_9f8a2e1c",  "status": "processing"}

This is worth pausing on, because it trips people up the first time. Submitting a document doesn't process it synchronously. IDPForge accepts the file, queues it, and hands you back an ID so you can check in on it. Depending on document size and pipeline complexity, processing can take anywhere from a couple of seconds to closer to a minute. Treat the submit call as a hand-off, not a request-response round trip.

Step 3: Read The Result

There are two ways to find out when a job is done. You can poll the job status endpoint, or you can subscribe to a job.completed webhook and get notified the moment it finishes. Polling is the faster path to a first result, so that's what this walkthrough uses. Webhooks are the better production pattern, and worth their own post.

To poll, hit the job endpoint with the ID you got back:

curl https://api.idpforge.ai/v1/jobs/job_9f8a2e1c \  -H "X-API-Key: idpf_sandbox_xxxxxxxxxxxxxxxx"

Once the job status flips to completed, the response includes the extracted fields, each with a value and a confidence score:

{  "job_id": "job_9f8a2e1c",  "status": "completed",  "fields": {    "vendor_name": { "value": "Meridian Supplies Inc.", "confidence": 0.97 },    "invoice_number": { "value": "INV-20458", "confidence": 0.99 },    "invoice_date": { "value": "2026-08-14", "confidence": 0.95 },    "total": { "value": "4,812.50", "confidence": 0.61 }  }}

Look at that last field. The total came back at 0.61 confidence, noticeably lower than everything around it. That's not a bug, and it's not IDPForge being unsure in a way you should distrust. It's the system doing exactly what it's supposed to do: flagging a field where the extracted value might not match what's actually on the document, usually because of a smudge, an unusual layout, or a total that's split across two lines.

Low confidence isn't wrong. It's a signal. On a pipeline with review enabled, a field like this wouldn't ship silently into your downstream system. It would raise a low_confidence exception and land in a review queue, where a human confirms or corrects it before the job is marked complete. The sandbox pipeline you just ran has review turned off, so you see the raw number instead of the queue behavior. But the mechanism is the same one that governs production traffic once you turn it on.

What Just Happened, Underneath

None of what you just did was IDPForge improvising on the fly. The std-invoice pipeline you submitted to already had Source, Extract, and a bound schema (AP Invoice v3) fully configured before you ever sent a request.

That's the piece worth naming, even briefly. A pipeline in IDPForge is a full, versioned configuration: source, initialization, parse, split & classify, extract, post-processing, and destination; and the seeded sandbox pipeline is a real, working instance of that anatomy, not a stripped-down demo mode. You didn't skip the setup. It was done for you, once, so you could see the output first and the configuration second.

That ordering is deliberate. Understanding what a completed extraction looks like makes it much easier to reason about pipeline configuration later, instead of configuring blind and hoping the output matches what you expected.

Where To Go Next

Everything above uses a pipeline someone else configured for a document type someone else chose. The natural next step is making that setup yours.

Configure your own pipeline. Your documents aren't standard invoices, so at some point you'll want your own document classes, your own schema, and your own validation rules bound to a pipeline you built rather than one that shipped as a sample. That's a longer walkthrough, and it moves through Parse, Split & Classify, Extract, and Post-Processing one stage at a time.

Move off polling onto webhooks. Polling works for a five-minute test. It doesn't work well once you're running hundreds of jobs a day, where you'd rather be notified than repeatedly ask. Signed job.completed webhooks close that gap, and they're worth setting up before you put anything real through IDPForge.

Both of those are genuinely deeper topics, and this post was never meant to cover them. The goal here was minutes: a key, a job, a result. If you've got that, the rest of IDPForge is just more of the same pattern, one stage at a time.