Permanently redact personal information | CloudRaker documentation

{
  "object": "string",
  "id": "string",
  "status": "queued",
  "expiresAt": "string",
  "statusUrl": "string",
  "files": [
    {
      "id": "string",
      "name": "string",
      "status": "string",
      "error": "string"
    }
  ],
  "file": {
    "id": "string",
    "name": "string",
    "status": "string",
    "error": "string"
  },
  "error": {
    "code": "string",
    "message": "string"
  },
  "metadata": {},
  "output": {
    "files": [
      {
        "id": "string",
        "name": "string",
        "url": "string"
      }
    ],
    "file": {
      "id": "string",
      "name": "string",
      "url": "string"
    },
    "entities": {},
    "skipped": 1.1
  }
}

Destructively removes personal information from a document or an audio file and returns a new file.

The removal is real, not cosmetic: text is stripped out of the PDF content stream rather than covered with a black box, and audio is beeped or silenced with its transcript rewritten to match.

Routing is by the input’s media type, and the parameters are not interchangeable:

Documents — mode: targeted (default, per-entity boxes) or lines (whole lines).
Audio and video — style: beep or silence.

Sending the other medium’s parameter is a 400.

Choosing what to remove. categories lists what counts as sensitive; the defaults cover names, government ids, addresses, phone numbers, email addresses and dates of birth. instructions adds free-form guidance on top. The result reports output.entities — a per-category count of what was removed — and output.skipped, the documents that had nothing to redact.

{
  "file": { "id": "a04d6597-4e34-4a99-94ea-964c289a4c68" },
  "categories": ["ssn", "ein"],
  "mode": "targeted"
}

Waiting for the result

Sync by default: the call holds open until the run finishes, up to ?wait= seconds (default 60, max 120, 0 returns immediately).

Outcome	Response
Finished inside the window	`200` with the full run
Still running at the cap	`202` with `{object, id, status, statusUrl}`

The 202 is a graceful degrade, never an error — poll the run or wait for a webhook. Replaying an idempotency-key returns the original run alongside an idempotent-replay: true response header.

Learn more: Redaction guide

Authentication

AuthorizationBearer

Bearer authentication of the form Bearer <token>, where token is your auth token.

Path parameters

spaceIdstringRequired

Query parameters

waitintegerOptional0-120Defaults to 60

How many seconds to hold the request open waiting for the run to finish.

Finishing inside the window returns 200 with the full run; running past it returns 202 with a statusUrl to poll. Send 0 to skip waiting entirely and always get the 202.

Request

This endpoint expects an object.

fileobjectRequired

An input file, given one of two ways.

{ "url": "…", "name"?: "…", "processing"?: "…" } — fetched over http(s) for this run and purged with it.
{ "id": "…" } — a file you already registered with POST /v1/files, reusable across runs and never re-parsed.

categorieslist of stringsOptional

instructionsstringOptional<=4000 characters

modeenumOptional

Allowed values:

styleenumOptional

Allowed values:

actionstringOptional>=1 character

metadatamap from strings to anyOptional

Arbitrary JSON you attach to the run and get back on every read of it.

Use it to carry your own identifiers — an order number, a customer id — so a webhook or a polled run reconciles without a lookup table. Capped at 10 KB serialized.

webhookobjectOptional

Where to deliver this run's events, given one of two ways.

{ "url": "…" } — a one-off https endpoint for this run only.
{ "id": "whe_…" } — a saved endpoint from POST /v1/webhooks. Runs hold the reference, so pausing or re-pointing that endpoint applies to this run too.

Deliveries are at-least-once and signed — dedupe on eventId and verify against GET /v1/webhooks/jwks.json.

ttlintegerOptional1-604800Defaults to 86400

How long, in seconds, to keep this run and its files before purging them automatically.

The maximum is 604800 (7 days). The deadline comes back as expiresAt on every read of the run. Call POST /v1/runs/{id}/keep before then to clear the TTL and move the results into a space permanently.

E-signature runs are exempt — an envelope waits for its signers however long that takes.

Response

The finished run.

object"redact_run"

idstring

statusenum

Where the run is in its life.

Status	Meaning
`queued`	Accepted, not started
`processing`	Work in flight
`needs_input`	Waiting for an external action, such as an e-signature
`processed`	Finished; `output` is populated
`failed`	Finished unsuccessfully
`cancelled`	Stopped on request
`expired`	TTL elapsed and the data was purged

The last four are terminal.

expiresAtstring or null

statusUrlstring

fileslist of objects

fileobjectOptional

errorobjectOptional

Why the run failed. Present whenever status is failed, and only then.

code is the stable, snake_case reason (input_unavailable, parse_failed, …); message is the human-readable detail. Per-file and per-step failures are also reported in files[].error and, for a pipeline, steps[].error.

metadatamap from strings to anyOptional

outputobjectOptional

The redacted files. Present once status is processed.

files[] holds the new documents — file is an alias of the first for single-file runs — each with a signed download link. entities tallies what was removed per category, and skipped counts documents that contained nothing to redact and so produced no new file.

Errors

400

Bad Request Error

422

Unprocessable Entity Error

429

Too Many Requests Error