Skip to main content

Jobs

Long-running operations on the Scripe API (post generation, knowledge base ingest, source ingest from file) run as async jobs. The endpoint that submits one returns a Job envelope; you poll GET /v1/jobs/{jobId} (or use wait_for_completion_ms for short jobs) until the status leaves QUEUED/RUNNING. The job lifecycle is: Workers update progress to a separate Redis key with a 1-hour TTL, so the progress snapshot on GET /v1/jobs/{jobId} may be null if the job hasn’t started or has already finished.

Job types

Wave 3 ships only POST_GENERATION. The other types appear in the enum / OpenAPI spec for forward-compat but the endpoints land in Wave 4.

GET /v1/jobs

List jobs in the workspace, newest first.

Query parameters

Response

The list endpoint omits live progress to keep it cheap. Fetch /v1/jobs/{jobId} for the freshest snapshot.

Errors


GET /v1/jobs/{jobId}

Fetch a single job + its latest progress snapshot.

Response

While the job is running you’ll see a progress payload:
progress is null when the job is still QUEUED or has already finished (the Redis key has a 1-hour TTL).

Polling cadence

Workers emit ~10 progress updates per POST_GENERATION. Poll once per second while status is RUNNING. Long-running types (KB_INGEST_*) emit fewer updates — back off to once every 5 seconds after the first 30 seconds.

Errors


POST /v1/jobs/{jobId}/cancel

Cancel a QUEUED job. v1 does NOT support cancelling RUNNING jobs (workers don’t poll for cancellation mid-run); attempting to cancel one returns 409 not_cancellable.

Response

The freshly-cancelled job, with status: "CANCELLED" and a populated completedAt:

Errors


AI spend cap

Every job that runs an AI workload (currently: POST_GENERATION) is gated by a daily workspace spend cap (per UTC day). The pre-flight check happens at submit time: When a submit would put the workspace over the cap, the API returns 402 spend_cap_exceeded with the current spentCents and capCents in the error meta. The bucket resets at 00:00 UTC.