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 aJob 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
/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 perPOST_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, withstatus: "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.