Inside the CloudRaker API: one pipeline, from raw PDF to signed document

CloudRaker is the paperwork infrastructure. That's the tagline. This is what it means in code.

Back to journal

Most document APIs solve one stage of the problem. You get an OCR engine, or a structured-extraction model, or an e-signature tool, and you wire the rest together yourself: mapping code between vendors, retry logic when one step fails, and no single source of truth for what happened to a document from intake to sign-off.

CloudRaker exposes the whole flow (parse, extract, redact, fill, sign, and hand off to a human or an agent) as one API, callable as individual steps or chained into a single pipeline call with one run id. This post walks through how that works, using a real workflow end to end.

The shape of the API

Everything lives behind one gateway:

Base URL:      https://api.cloudraker.com
Auth:          Authorization: Bearer <org_api_key>
Format:        JSON in, JSON out
Rate limit:    ≥ 67 requests/minute per organization, shared across all endpoints

One key, one org. The gateway resolves your tenant from the token, authorizes the call, and dispatches to whichever capability you're hitting; you never pass a tenant id yourself. SDKs exist for TypeScript and Python if you'd rather not hand-roll the HTTP calls.

The use case: onboarding a new vendor contract

To make this concrete, here's a workflow a procurement or legal-ops team runs constantly: a new vendor sends over a signed contract as a scanned PDF, and before it goes into the system of record, someone has to read it, pull out the key terms, strip anything sensitive that shouldn't be stored raw, generate an internal approval cover sheet, get a compliance sign-off, and collect a final counter-signature.

Done by hand, that's four or five people touching the same document over a few days. This is what it looks like as one CloudRaker pipeline.

Step 1 — Register the file

Every run starts from a registered file, not a raw upload each time. Point CloudRaker at the document once, by URL or presigned upload, and reuse it across every step that follows: it gets parsed once, not once per capability.

curl -X POST https://api.cloudraker.com/v1/files \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source_url": "https://vendor-portal.example.com/contracts/acme-msa.pdf",
    "name": "Acme MSA - signed"
  }'

Step 2 — Parse it into clean text

No schema needed here: just turn the scanned PDF into clean markdown or structured JSON so every later step is working with text, not pixels.

curl -X POST https://api.cloudraker.com/v1/parse \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{ "file_id": "file_9f2a..." }'

Step 3 — Extract the terms that matter

This is where CloudRaker's extraction model earns its keep: give it a JSON Schema describing what you care about, and it returns data shaped exactly like that schema, with a page-and-region citation behind every field, so nothing is a black box.

curl -X POST https://api.cloudraker.com/v1/extract \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{
    "file_id": "file_9f2a...",
    "schema": {
      "type": "object",
      "properties": {
        "counterparty": { "type": "string" },
        "term_months": { "type": "integer" },
        "renewal_notice_days": { "type": "integer" },
        "payment_terms": { "type": "string" }
      }
    }
  }'

The response includes a source reference for each field (p. 4, p. 6), the same citation model you'd see in the extraction grid in the product itself. That traceability matters more here than accuracy alone: a legal team can verify a field in seconds instead of re-reading the whole contract.

Step 4 — Redact before it's stored

Contracts often carry signatory personal details that shouldn't sit in a general-purpose records system unredacted. Strip them before the document moves further downstream:

curl -X POST https://api.cloudraker.com/v1/redact \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{ "file_id": "file_9f2a...", "targets": ["signatory_personal_info"] }'

Step 5 — Fill the internal cover sheet

Take the fields extracted in step 3 and fill your own internal approval template, with no manual re-typing of the same data into a second document.

curl -X POST https://api.cloudraker.com/v1/fill \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{
    "template_id": "tmpl_approval_cover_v4",
    "values": { "client_name": "Acme Corp", "term_months": 36 }
  }'

Step 6 — Hand off for compliance sign-off (agent run)

This is the step most "document API" products don't have an answer for. A compliance reviewer needs to sign off before the contract is final, and you want an agent handling the coordination rather than a person chasing Slack messages. An agent run manages exactly this: a multi-step process on a set of files that pauses for a human sign-off and resumes when it's given.

curl -X POST https://api.cloudraker.com/v1/agent-runs \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{
    "file_ids": ["file_9f2a..."],
    "workflow": "contract-compliance-review",
    "assignee": "compliance-team"
  }'

Your application polls the run (or better, listens for it) rather than building its own state machine for "waiting on a human."

Step 7 — Collect the final signature

Once compliance signs off, the contract goes out for e-signature, with a sealed audit trail behind it:

curl -X POST https://api.cloudraker.com/v1/sign \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{ "file_id": "file_9f2a...", "signer_email": "legal@acme.example.com" }'

Or: all of it, in one call

Steps 2 through 5 (and, depending on your workflow, further) don't have to be separate round trips. A pipeline runs several capabilities over one file set in a single call: one run id, one result to poll, and the file is only parsed once no matter how many steps come after it:

curl -X POST https://api.cloudraker.com/v1/pipelines \
  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
  -d '{
    "file_id": "file_9f2a...",
    "steps": ["parse", "extract", "redact", "fill"],
    "schema": { "...": "as above" }
  }'

The differentiator: this isn't five vendors' worth of glue code and five places something can silently fail between steps. It's one run, one status to check, one place the audit trail lives.

Step 8 — Know when it's done

Rather than polling in a loop, subscribe to signed webhooks and react to run events as they happen. Every delivery is a public-key-signed JWT you verify against a published JWKS, so there's no shared secret sitting in an environment variable somewhere:

import { CloudRaker } from "@cloudraker/sdk";

const client = new CloudRaker({ apiKey: process.env.CLOUDRAKER_API_KEY });

app.post("/webhooks/cloudraker", async (req, res) => {
  const event = await client.webhooks.verify(req.body, req.headers);
  if (event.type === "run.completed") {
    // move the fully processed, signed contract into the system of record
  }
  res.sendStatus(200);
});

What this removes

Run that same workflow without CloudRaker and you're integrating: an OCR/parsing vendor, a separate extraction model (or a hand-rolled prompt-and-parse layer), a redaction step you probably build yourself, a forms tool, a workflow engine for the human-in-the-loop compliance step, and an e-signature API, each with its own auth, its own rate limits, its own failure modes, and a set of glue code in the middle that nobody enjoys maintaining.

The pipeline above replaces that whole stack with a handful of API calls against one gateway. That's the meaning behind "paperwork infrastructure": not a slicker parser, but the plumbing you'd otherwise have to build yourself, already built.

Where to go from here

If you're currently maintaining your own version of the stack above, we'd like to hear where it hurts most; that's the feedback shaping what we build next.

Read this next

All posts