jobs

Get Job processing details

Changed on

Retrieve processing details for a specific job by its ID.

get/api/v1/jobs/{job_id}/details

Request

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

Path parameters

job_idstring uuid required

Headers

unstructured-api-keystring nullable

Response

Successful Response

idstring uuid required
processing_status'SCHEDULED' | 'IN_PROGRESS' | 'SUCCESS' | 'COMPLETED_WITH_ERRORS' | 'STOPPED' | 'FAILED' | 'REJECTED' required
messagestring nullable
queued_behind_job_ids_snapshotstring[] nullable

Job ids that held this workspace's concurrency slots at the instant this run was queued. Taken once and never refreshed, so the jobs named here may have finished long ago. It is not the set of jobs this run is waiting on, and it errs in both directions: runs queued ahead of this one but not yet started sit on the FIFO queue rather than in a slot, so they are absent; and the snapshot is taken at queue time whether or not the jobs it names are what kept this run waiting, since a held slot is not by itself the workspace being full at its tenant_max_concurrent_jobs limit. Show it as what held a slot at that moment, never as the cause of a delay or as a complete list of blockers. Null means no snapshot exists -- the run did not go through the queue, or the read failed -- which is not the same as [], meaning the snapshot was taken and nothing held a slot. For what is running now, read progress.other_active_jobs, which is a live read.

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

  • 1ff8d52838c2Revision changes
    • breaking

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

    • breaking

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

  • fbaf6c043e7bRevision changes
    • 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

    • 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

    • info

      added the optional property to the response with the status