List the placeholders an automation may write
const url = 'https://api.pixonaut.app/v1/automations/placeholders';const options = {method: 'GET', headers: {Authorization: 'Bearer <token>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url https://api.pixonaut.app/v1/automations/placeholders \ --header 'Authorization: Bearer <token>'Operation ID: automations.placeholders
Every placeholder an automation’s texts may name, by namespace, with what it holds, whether it can be empty, and whether it is personal data, which only an action bound for the order’s own printshop may write. A text writes {order.id}, {{ for a brace of its own, {order.reference ?? "none"} for a fallback, and {actions.<step>.id} for what an earlier step made. A save refuses a name not listed.
Authorizations
Section titled “Authorizations”Responses
Section titled “Responses”The placeholders
object
object
What the namespace holds.
Its placeholders; none for actions, whose {actions.<step>.id} names an earlier step by its id.
object
Whether a firing can leave it empty: give it a fallback, {order.reference ?? "none"}.
What it holds.
Personal data: written only in an action bound for the order’s own printshop.
The placeholder as a text writes it: {order.id}.
Examples
Example
{ "namespaces": [ { "description": "The order the firing acts on, once it has one.", "namespace": "order", "placeholders": [ { "canBeEmpty": false, "description": "The order's id.", "personal": false, "token": "{order.id}" }, { "canBeEmpty": true, "description": "Your reference for the order.", "personal": false, "token": "{order.reference}" }, { "canBeEmpty": true, "description": "The recipient's email.", "personal": true, "token": "{order.recipient.email}" } ] }, { "description": "What an earlier step made: `{actions.<step>.id}` is the id of the print file or order the step with that id made.", "namespace": "actions", "placeholders": [] } ]}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
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"}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].