Skip to content

Change a job's status

Open .md

PUT/v2/api/store/{team_slug}/v2/job/{hash_id}/status

v2Operation ID v2_public_job_change_status

Check success, not only the HTTP status: when the job's order isn't published (a draft), this call answers HTTP 200 with { "status": 500, "success": false, "error": { "code": "action_not_allowed", "message": null } } and changes nothing.

Moves a job to another of your team's job statuses. Returns the job with previous_status_id, previous_status and participant_emails (the order's message participants who receive email).

A job's production stage is its status. The job's current status is status_id (and the status object, with its label, type and position) on the job, as Get one job of an order and the job lists return it. Statuses are set up per team (List job statuses); each has a type: Pending (start), In Progress (pre_production or in_progress) or Completed (end).

To move a job to the next stage: read the job's status_id, list the job statuses, sort them by position, send the id of the one after the current one here, and check success in the reply. Tasks are separate: they track the steps inside a job, and finishing them doesn't move the job.

Sending the status the job already has is accepted and changes nothing.

Permission

Any member of the team; this route checks no sales order permission.

Business rules

  • The job's order must be published. On a draft the reply is HTTP 200 with success: false and error.code action_not_allowed, and nothing changes.
  • The status must be a job status of your team; a task preset status is a 404.

Side effects

  • Sends the job.status_changed webhook, only when the status really changed.
  • Records the change in the status history and the order's activity log, and updates status_last_change_date (and status_completion_date for a Completed status).
  • Moving to a Completed status rechecks the order's shipments: a shipment whose jobs are all Completed is marked ready to ship.

Path parameters

  • team_slugstringrequired

    Your team slug, shown as Team ID next to your API key in Profile.

    • Example your-team
  • hash_idstringrequired

    The job's hash id (id). Hash ids only: a unique key or a document number gives 404.

    • Example WaGvtaWsx7Kcn4

Query parameters

  • Optional. 1 (or true, yes, on) makes the answer smaller: each mockup and production file's current_approval leaves out its items list, and every other key stays as it is. The job's pending_approval and webhook payloads keep their items. Every file repeats its approval with all of its items, so a job with many files on one approval answers with far less data this way; read approval items from the approvals operations instead. Left out (or any other value), the answer is unchanged. Only the query string is read: a body field with this name is ignored.

    • Example 1

Request body

application/json, required.

  • status_idstringrequired

    A job status of your team (from List job statuses).

  • notify_customerboolean | null

    Accepted and ignored: this route sends the customer nothing.

Response

200Successful response.

Errors

  • 401The API key is missing or wrong (unauthenticated).

  • 403You are not allowed to do this. api_access_not_in_plan: your team's plan doesn't include API access (Pro and above, with an active subscription or trial), so every request answers this until the team upgrades. When your role lacks the permission the operation needs, the body is only {"message": "Insufficient Permission"}. Other refusals use the error envelope, with unauthorized or user_is_not_authorized.

  • 404Not found. page_not_found: the team slug is unknown, you are not a member of the team, or an id in the path is not one of this team's. code: null, with a message that starts "No query results for": there is no record with that id.

    When
    The job or the status isn't your team's, the job's order is an old (version 1) order, or the status isn't a job status.
    Fix
    Use a status id from List job statuses.
  • 422The request was refused and changed nothing. validation_failed lists what to fix in error.fields; other codes name a business rule, explained in error.message. A few checks answer with only {"message": "..."}. An operation that calls another service (a payment provider, a carrier, an accounting app) can answer connect_timeout ("Please retry again") when that service does not answer in time: the change may or may not have happened there, so read the record back before you retry.

    When
    status_id is missing or not a hash id.
    Fix
    Send status_id.

Notes

  • A refusal here is HTTP 200 with success: false and error.code action_not_allowed (the body's status says 500). A client that only checks the HTTP status will treat it as done.