jobs

Create a new on-demand job using either a template (with persistent job optimization) or custom DAG.

post/api/v1/jobs/

Request

  • Base URL
    https://platform.unstructuredapp.io
  • URL
    https://platform.unstructuredapp.io/api/v1/jobs/
  • Auth
    none declared

Headers

unstructured-api-keystring nullable

Request body multipart/form-data

input_filesstring[] nullable
input_file_idsstring[] nullable
request_datastring required

Response

Successful Response

idstring uuid required
workflow_idstring uuid required
workflow_namestring required
status'SCHEDULED' | 'IN_PROGRESS' | 'COMPLETED' | 'STOPPED' | 'FAILED' | 'REJECTED' required
stop_requestedboolean
created_atstring date-time required
runtimestring duration nullable
input_file_idsstring[] nullable
job_type'ephemeral' | 'persistent' | 'scheduled' | 'template'
created_by_idstring uuid nullable
reasonstring nullable

Sanitized failure reason for a FAILED job; None otherwise.

processing_status'SCHEDULED' | 'IN_PROGRESS' | 'SUCCESS' | 'COMPLETED_WITH_ERRORS' | 'STOPPED' | 'FAILED' | 'REJECTED'
failed_file_countinteger nullable

Documents that failed so far. Read it against processing_status, which says whether the job has reached a verdict: on a job that has not finished, 0 means none recorded yet, not that every input produced output.

completion_issue'NO_DOCUMENTS_DISCOVERED' | 'NO_DOCUMENTS_SUCCEEDED'

Why a COMPLETED job delivered no document.

Read for what a run did; the verdict only says whether anything was lost. A run whose source handed back nothing finishes processing_status: SUCCESS with an empty destination, and without this there is no statement anywhere that it moved nothing (Pylon 2287, PLU-622). A run that discovered documents and delivered none of them without failing any is FAILED, and carries this for the same reason: nothing else on the row explains it. A run whose documents failed carries none of these; /failed-files explains it.

So the verdict cannot be used to find these runs, and a caller that wants to know whether a job delivered anything branches on this field.

Its own type on its own nullable field, deliberately NOT a JobProcessingStatus member: that enum is on the public wire and a closed generated-SDK enum breaks a whole list_jobs page on one unrecognised value (DTPL-696, REJECTED).

Null is "no issue detected", never "checked and fine" -- a caller must not read the absence of a value as a guarantee, and a job FAILED for some other reason (a failed document, a preflight rejection) carries none of these. New members may be added; treat an unrecognised one as "an issue was detected, of a kind this client does not know".

Changes

    • breaking

      the /// response's property format changed from uuid to no format for status

    • info

      added the non-success response with the status

    • info

      added the non-success response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status

    • info

      added the optional property to the response with the status