Approve a committed design
const url = 'https://api.pixonaut.app/v1/designs/example/approve';const options = { method: 'POST', headers: {Authorization: 'Bearer <token>', 'Content-Type': 'application/json'}, body: '{"consent":{"at":1790000050000,"kind":"checkbox","ref":"WEB-10482"},"expectedRevision":1}'};
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/example/approve \ --header 'Authorization: Bearer <token>' \ --header 'Content-Type: application/json' \ --data '{ "consent": { "at": 1790000050000, "kind": "checkbox", "ref": "WEB-10482" }, "expectedRevision": 1 }'Operation ID: designs.approve
Approves now, or after afterDays days when the tenant wants a window for the customer to change their mind. Safe to retry: approving now a design already approved at expectedRevision (or at any revision, when none is given) answers approved again and records nothing more; one rejected, or approved at another revision, is refused not_committed. Through a deciding proof page link, approves now only, must carry expectedRevision (else bad_request), and is refused proof_outdated unless the design’s proof shows its current revision, which a design committed without a proof never has.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Request Body
Section titled “Request Body”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.
How the customer agreed to the design, kept on it (approvalConsent) and in the approval’s audit entry. Left out, none is kept. Through a deciding proof page link, refused bad_request: the link’s approval records its own, a proof_page consent naming the link.
object
When the customer agreed, epoch milliseconds.
How the customer agreed: by adding the design to their cart, by ticking a box, on a proof page, by approving it again on your store after correcting it (edit), or by letting your store’s own approval deadline pass (deadline). More kinds may be added.
Your own reference for the consent, such as the cart line or checkout it was given at. Through a proof page link, the link’s id.
The design’s revision as the caller read it. When the design has been corrected since, the decision is refused revision_changed with the revision it has now. Required through a proof page link: a customer decides the revision whose proof they were shown.
Examples
A connected store, from connect to delivery: 4. Approve it, with the customer's consent
{ "consent": { "at": 1790000050000, "kind": "checkbox", "ref": "WEB-10482" }, "expectedRevision": 1}Design to order: 2. The merchant's server approves it
{ "afterDays": 14}Example
{ "afterDays": 3, "consent": { "at": 1791770340000, "kind": "checkbox", "ref": "order-1042" }, "expectedRevision": 2}Sending the customer back to the store: Correcting a design from the store
{ "consent": { "at": 1790000200000, "kind": "edit", "ref": "edit-7c1e" }, "expectedRevision": 2}Responses
Section titled “Responses”Approved now, or scheduled to be
object
Examples
A connected store, from connect to delivery: 4. Approve it, with the customer's consent
{ "status": "approved"}Design to order: 2. The merchant's server approves it
{ "status": "approved"}Design to order: 2. The merchant's server approves it (2)
{ "status": "scheduled"}Example
{ "status": "scheduled"}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: not_found
object
Examples
not_found
{ "error": "not_found"}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: not_committed, proof_outdated, revision_changed
object
Always sent with revision_changed.
Examples
not_committed
{ "error": "not_committed"}proof_outdated
{ "error": "proof_outdated"}revision_changed
{ "error": "revision_changed", "revision": 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: 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: rate_limited
object
Examples
rate_limited
{ "error": "rate_limited"}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].