Full metadata for a batch job
Lists all information about a submitted batch job.
Response
Full job information.
Per-back-end unique identifier of the batch job, generated by the back-end during creation. MUST match the specified pattern.
A short description to easily distinguish entities.
Detailed multi-line description to explain the entity.
CommonMark 0.29 syntax MAY be used for rich text representation.
The current status of a batch job.
The following status changes can occur:
- POST /jobs: The status is initialized as created.
- POST /jobs/{job_id}/results: The status is set to queued, if
processing does not start instantly.
- Once the processing starts the status is set to running.
- Once the data is available to download the status is set to finished.
- Whenever an error occurs during processing, the status MUST be set to error.
- DELETE /jobs/{job_id}/results: The status is set to canceled if the status was running beforehand and partial or preliminary results are available to be downloaded. Otherwise the status is set to created.
The following state diagram shows the possible status changes:
Indicates the process of a running batch job, in percent. Can also be set for a job which stopped due to an error or was canceled by the user. In this case, the value indicates the progress at which the job stopped. This property may not be available for the status codes created and queued. Submitted and queued jobs only allow the value 0, finished jobs only allow the value 100.
Date and time of creation (for batch jobs: the status 'created' was set), formatted as a RFC 3339 date-time.
Date and time of the last status change, formatted as a RFC 3339 date-time. If the status is error, canceled or finished, this is the time when the job has ended.
Date and time of queueing the batch job (i.e., when the status 'queued' was set), formatted as a RFC 3339 date-time.
Date and time when the batch job started processing (i.e., when the status 'running' was set), formatted as a RFC 3339 date-time.
Time until which the batch job results are stored on the back-end, in UTC. Formatted as a RFC 3339 date-time.
The billing plan to process and charge the job or service with.
Billing plans MUST be handled in a case insensitive manner.
The plans can be retrieved from GET /, but the value returned here may not be in the list of plans any longer.
An amount of money or credits. The value MUST be specified in the currency the back-end is working with. The currency can be retrieved by calling GET /. If no currency is set, this field MUST be null.
Maximum amount of costs the request is allowed to produce. The value MUST be specified in the currency of the back-end. No limits apply, if the value is null or the back-end has no currency set in GET /.
The minimum severity level for log entries that the back-end stores for the processing request.
The order of the levels is as follows (from low to high severity): debug, info, warning, error. That means if warning is set, the back-end will only store log entries with the level warning and error.
The default minimum log level is info. Users need to specifically set this property to debug to capture all log entries. It is RECOMMENDED that users set the level at least to "warning" in production workflows.