--- title: "Mark items as ready for publishing in bulk." method: POST path: "/authoring/v1/changes/status/ready" tags: ["Authoring changes"] --- # Mark items as ready for publishing in bulk. `POST /authoring/v1/changes/status/ready` Use the `/changes/status/ready` endpoint to change the status of multiple items to the `ready` state. Currently only Assets and Content support for workflow states. ### Example Requests: ### #### Change the status of a content and an asset to the ready state #### Specify the items that you want to change to the ready state in the request body. ##### Request: ##### ~~~ { "ids": [ { "id": "579c2232-7398-4c8b-921d-3932bfc45d19", "classification": "content" }, { "id": "448e8d63-ed15-4d59-85e5-53908a84ca93", "classification": "asset" } ] } ~~~ #### Optionally provide a name for a set of changes. #### You can also optionally name the set of changes. ##### Request: ##### ~~~ { "name": "HalloweenContent", "ids": [ { "id": "579c2232-7398-4c8b-921d-3932bfc45d19", "classification": "content" } ] } ~~~ # #### Request with unique IDs #### Alternatively you can also make requests with the content hub unique ID. The unique ID is the items classification and the ID combined to create an ID that is unique across all content hub items. ~~~ { "ids": [ { "id": "content:579c2232-7398-4c8b-921d-3932bfc45d19" }, { "id": "asset:448e8d63-ed15-4d59-85e5-53908a84ca93" } ] } ~~~ ## Dealing with Errors: ## When the request succeeds for all items that was requested, then a `204` response is returned. However, if one or more items fail an error message is returned. # ### Error Types # __Mismatched revisions__ The revision that is provided of the item is not the current revision. Check whether you still want to proceed based on the recent state of the item and retry with recent revision. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"mismatched.revs.20000", "code": 20000, "parameters":{ "requestedRev": "a-1", "currentRev": "a-2" } } ~~~ # __Item is not in valid state__ Draft items are allowed to be saved with validation errors but the errors must be resolved before you can change the status from draft to ready. Resolve the validation errors and then retry the operation. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"invalid.item.20001", "code": 20001 } ~~~ # __Item not found__ The item that is specified was not found. Check whether the ID provided is correct, or if the item was deleted. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"not.found.20002", "code": 20002 } ~~~ # __Invalid Target State__ The Workflow status that this item is attempting to move to is not allowed from its current state. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"invalid.target.workflow.state.20003", "code": 20003, "parameters":{ "target": "ready", "current": "ready" } } ~~~ # __Workflow not supported for unmanaged assets__ Workflow actions are not supported for unmanaged developer assets. Refer to Asset documentation for clarification on managed versus unmanaged assets. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"unmanaged.asset.20005", "code": 20005 } ~~~ # __Dependencies Failed__ The status of the item cannot be changed because one or more of its dependencies failed. In this case, refer to the dependency error to find the root cause. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"dependencies.failed.20100", "code": 20100, "parameters":{ "dependencies": [ "content:b"] } } ~~~ # __Missing dependencies__ The status of the item cannot be changed because one or more of its dependencies were not specified. Review whether to include the dependent items in this operation and if so repeat the bulk request with the IDs included. ~~~ { "uid":"content:a", "id":"a", "classification":"content", "key":"missing.dependencies.20200", "code": 20200, "parameters":{ "missing": [ "asset:c" ,"asset:d"] } } ~~~ # __Generic Error__ Something unexpectedly went wrong trying to complete the action on this item. ~~~ { "uid":"asset:g", "id":"g", "classification":"asset", "key":"error.generic.1000", "code": 1000 } ~~~ ## Example responses Now some full examples ### Example 1 - Item failed due to dependency failure. Request ~~~ { "ids": [ { "id": "content:a" }, { "id": "content:b" }, { "id": "content:c" } ] } ~~~ # Response ~~~ { "missing":[], "genericErrors":["content:a"], "userErrors":["content:b"], "successful":["content:c"] "messages":{ "content:a":{ "uid":"content:a", "id":"a", "classification":"content", "key":"dependencies.failed.20100", "code": 20100, "parameters":{ "dependencies": ["content:b"] } }, "content:b":{ "uid":"content:b", "id":"b", "classification":"content", "key":"invalid.item.20001", "code": 20001 } } } ~~~ # In the example that is shown, the goal was to change the status of the items with IDs `a`, `b`, and `c` to ready state. The item with ID `c` was successfully changed to ready state, while the item with ID `b` fails due to validation errors. Since item with ID `a` has a dependency to item with ID `b`, it also fails. ***Note:*** The response provides the IDs with the various arrays to provide context on the failure. The failure for item with ID `a` is grouped into the generic errors list since there is nothing to fix with the item `a`. Instead, the user must fix the validation errors with `b` and retry to change the status to ready for `a` and `b`. # ### Example 2 - Item failed due to missing dependencies. Request ~~~ { "ids": [ { "id": "content:a" } ] } ~~~ # Response ~~~ { "missing":["asset:c", "asset:d"], "genericErrors":[], "userErrors":[], "successful":[] "messages":{ "content:a":{ "uid":"content:a", "id":"a", "classification":"content", "key":"missing.dependencies.20200", "code": 20200, "parameters":{ "missing": [ "asset:c" ,"asset:d"] } } } } ~~~ # The status of draft items cannot be changed to ready if the draft item still has draft dependencies. In the example that is shown, content `a` has a reference to asset `c` and `d`. You can repeat the request for bulk ready with all three items included. Alternatively, you can use the Authoring reference API to check and obtain the connected items before you perform the bulk ready request.
User roles: admin, manager, editor ## Request body - object - `ids` object[] - `id` string - `classification` 'asset' | 'content' — The classification of the item. Only Assets and Content currently have workflow status. - `rev` string ## Response `200` See the status field to determine whether the request was successful. - object - `status` 'success' | 'partial' | 'failure' — Represents the success of the request. - `missing` string[] — These are dependencies of items that were requested. The operation should be repeated with these items also included. The format of the ids is the `uid` format with the classification and id combined. - `genericErrors` string[] — These are items that failed for system are not actionable directly by the API user. They may indicate system errors and also dependent errors i.e. where the item failed because its dependency failed. The format of the ids is the `uid` format with the classification and id combined. - `userErrors` string[] — These are items that failed for breaking various rules that make the operation valid. These are the actionable errors. The format of the ids is the `uid` format with the classification and id combined. - `successful` string[] — Even when there are failures some items can succeed, this is the list of ids that succeeded. The format of the ids is the `uid` format with the classification and id combined. - `messages` object ## Other responses - `429` — Too Many Requests, the server has reached a limit, the request must be sent again at a later time. - `503` — The service is currently unavailable. Try again later. - `default` — Unexpected error. --- [API](https://skmtc.net/goacoustic/apis/acoustic-content-api.md) · [All operations](https://skmtc.net/goacoustic/apis/acoustic-content-api/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/goacoustic/acoustic-content-api/revisions/677305266d89/schema)