Process documents

Spaces

A named container for files and runs, with a lifetime you set. The whole API is mirrored inside it.
View as Markdown

Without a space, every call happens in a hidden workspace. Files there are temporary and unindexed. They die with the run that used them. A space is the opposite. Files belong to the space and outlive their runs. They are indexed, so you can search them.

Use a space when several calls belong together: one customer onboarding, one case file, one batch you want to search later.

Create a space

$curl -X POST https://api.cloudraker.com/v1/spaces \
>  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
>  -H "Content-Type: application/json" \
>  -d '{ "name": "Acme onboarding", "ttl": 604800 }'
1{
2  "object": "space",
3  "id": "2f6d1c48-9b7a-4b2c-9a3e-1d5f8c0b7e21",
4  "name": "Acme onboarding",
5  "createdAt": "2026-08-15T09:12:00.114Z",
6  "expiresAt": "2026-08-22T09:12:00.114Z"
7}
FieldWhat it is
nameOptional, ≤ 120 characters. Defaults to API space.
ttlSeconds until the space expires, from 300 to 7776000 (90 days). Defaults to 604800 (one week).

Lifetime

expiresAt is the deadline. Extend it at any time. The new ttl counts from now:

$curl -X PATCH https://api.cloudraker.com/v1/spaces/$SPACE_ID \
>  -H "Authorization: Bearer $CLOUDRAKER_API_KEY" \
>  -H "Content-Type: application/json" \
>  -d '{ "ttl": 2592000 }'

DELETE /v1/spaces/{spaceId} closes the space immediately and deletes its files. It is idempotent. Call it again to finish a purge that was too large for one pass.

Expiry is lazy

No background process sweeps expired spaces today. The first call that addresses an expired space closes it. The space is archived, its files are deleted in the background, and the call answers 404.

Design for three consequences:

  • A space past expiresAt is already gone as far as this API is concerned, even before anything touched it.
  • The space.expired webhook fires at that moment — once per space, not at the deadline. Advance warnings arrive with the sweeper later.
  • An explicit DELETE does not emit space.expired. Deleting your own space is not an expiry.

The namespaced mirror

Every /v1 route that works on the hidden workspace works inside a space, under /v1/spaces/{spaceId}/…:

Inside a spaceWhat it does
POST /v1/spaces/{spaceId}/extract (also extract/batch, parse, redact, fill, sign, pipeline)The capabilities, over the space’s files.
POST / GET / DELETE /v1/spaces/{spaceId}/files…Register, list, read and delete files — plus every file tool.
GET /v1/spaces/{spaceId}/runs and /runs/{id}The runs that happened in this space.
GET /v1/spaces/{spaceId}/search?q=…Search the space’s indexed files.
POST /v1/spaces/{spaceId}/agents, GET …/agents/{runId}Agent runs scoped to the space.

Bodies and responses are identical to the unscoped routes. Only the path changes.

The mirror works on any live space of your organization, including spaces people created in the app. Lifecycle does not. PATCH and DELETE accept only a space created with POST /v1/spaces, so this API can never change or delete a space a person made.

Search a space

$curl "https://api.cloudraker.com/v1/spaces/$SPACE_ID/search?q=termination%20clause&limit=10" \
>  -H "Authorization: Bearer $CLOUDRAKER_API_KEY"

Only files in a space are indexed. Files in the hidden workspace are not, so there is nothing to search there.

List spaces

$curl "https://api.cloudraker.com/v1/spaces?limit=50" \
>  -H "Authorization: Bearer $CLOUDRAKER_API_KEY"

Next steps

File tools

Convert, split, join and redline the files in a space.

Files

Registering documents and presigned uploads.

Webhooks

Including space.expired.

Runs

Reading results and keeping them.