Approve or reject several designs
const url = 'https://api.pixonaut.app/v1/designs/decisions';const options = { method: 'POST', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"action":"approve","designs":[{"expectedRevision":1,"id":"dsn_3f2a9c1e"},{"expectedRevision":2,"id":"dsn_8b41d07a"}]}'};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request POST \ --url https://api.pixonaut.app/v1/designs/decisions \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "action": "approve", "designs": [ { "expectedRevision": 1, "id": "dsn_3f2a9c1e" }, { "expectedRevision": 2, "id": "dsn_8b41d07a" } ] }'Operation ID: designs.decide
Approves or rejects up to 200 designs, each as POST /v1/designs/{id}/approve or /reject decides it: the same grant, the same refusals, its own event and audit entry. Each design answers its own outcome, in the order the request named them; one refused leaves the others to be decided, so a 200 may hold refusals. afterDays schedules each approval, and reason is kept on each rejected design. Repeating a decision that already stands answers it again and records nothing more. Deleting several designs is one DELETE /v1/designs/{id} each.
Authorizations
Section titled “Authorizations”Request Bodyrequired
Section titled “Request Bodyrequired”object
Approve after this many days instead of now, 1 to 60: a window for the customer to change their mind. Left out, the design is approved now.
The designs to decide, at most 200, each named once. Their outcomes are answered in this order.
object
The design’s revision as the caller read it. When the design has been corrected since, it is refused revision_changed with the revision it has now.
object
The designs to decide, at most 200, each named once. Their outcomes are answered in this order.
object
The design’s revision as the caller read it. When the design has been corrected since, it is refused revision_changed with the revision it has now.
Why the designs are rejected, kept on each and carried by its design.rejected event, as POST /v1/designs/{id}/reject keeps it.
Examples
Example
{ "action": "approve", "designs": [ { "expectedRevision": 1, "id": "dsn_3f2a9c1e" }, { "expectedRevision": 2, "id": "dsn_8b41d07a" } ]}Responses
Section titled “Responses”Each design’s outcome
object
Examples
Example
{ "outcomes": [ { "id": "dsn_3f2a9c1e", "ok": true, "status": "approved" }, { "error": "revision_changed", "id": "dsn_8b41d07a", "ok": false, "revision": 3 } ]}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: bad_request
object
Examples
bad_request
{ "error": "bad_request"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: unauthorized
object
Examples
unauthorized
{ "error": "unauthorized"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: origin_forbidden, forbidden, feature_disabled, workspace_suspended
object
The feature the tenant does not have. Always sent with feature_disabled.
Examples
feature_disabled
{ "error": "feature_disabled", "feature": "api"}forbidden
{ "error": "forbidden"}origin_forbidden
{ "error": "origin_forbidden"}workspace_suspended
{ "error": "workspace_suspended"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: payload_too_large
object
Always sent with payload_too_large.
Examples
payload_too_large
{ "error": "payload_too_large", "maxBytes": 0}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Refused: db_error. A request that failed unexpectedly answers as text instead.
object
Examples
db_error
{ "error": "db_error"}Headers
Section titled “Headers”Every response names the request it answers in X-Request-Id: the id the request was sent with in that header, when it is well formed, else one the API gave it. Quote it when reporting a refusal or a failure: the API’s log lines for that request carry it.
Questions? Write to [email protected].