Complete a job
Marks a job as completed along with its result. The result shape is selected by the type field in the body
and must match the job’s type. It is a no-op for a job already in a terminal state (completed, cancelled,
failed); a pending_cancellation job can still be completed if it finishes before the cancellation is processed.
Requires write access to jobs.
Authorizations
Bearer authentication header of the form Bearer <token>, where <token> is your auth token.
Path Parameters
Unique identifier for a job.
Body
Marks a job as completed along with its result. The body is polymorphic: the type field selects the result
shape, which must match the job's type. The remaining fields depend on type.
Common variants:
forecast—{ "type": "forecast", "cost": <integer>, "rows": <integer> }refresh_materialized_view—{ "type": "refresh_materialized_view", "snapshot_id": "<string>", "row_stats": { "affected_rows": <integer>, "inserted_rows": <integer>, "updated_rows": <integer>, "deleted_rows": <integer> } }datasets_execute_dml—{ "type": "datasets_execute_dml", "affected_rows": <integer>, ... }
Other supported type values include datasets_create_table, datasets_truncate_table, datasets_delete_table,
datasets_deliver_data, datasets_calculate_column_stats, datasets_suggest_mappings, model_inference_run,
model_training_run, models_deliver_model, models_train_classifier, and health_check.
Discriminator selecting the result shape. Must match the job's type.
Response
OK
Unique identifier for the job.
The data plane the job runs on.
failed, cancelled, completed, pending, scheduled, pending_cancellation, running The type associated with the job. Jobs can have a type of nql-forecast or materialize-view.
- Option 1
- Option 2
The internal job executor tied to the job.
The type of the execution cluster to run the job on.
dedicatedruns job on a dedicated cluster.sharedruns job on a shared cluster.
dedicated, shared causes of job failure
The unique ID associated with the job.
The output of a materialized view.
- Option 1
- Option 2
The timestamp representing when the job was created.
The timestamp representing when the job was updated.
When the job's current attempt started. A job can be retried; each retry is a new attempt, so this advances to the latest one, while created_at stays at the original submission.
Which attempt this is: 1 for the first, increasing by one on each retry.
The timestamp representing when the job finished.
The compute pool associated with the job, if any.

