The API defines an interface to the following elements:
Jobs can refer to one or more documents and to resources. The job contains the document list and optionally the imposition schema (layout), print mode, operations (workflow steps) and other specific instructions for the printer or cutter. For more information about the job structure refer to the job documentation.
Resources are items like labels, calibrations, templates, etc. The resources are versioned and its history is retained for 30 days. Jobs, documents and devices are not versioned and modifications are immediate.
Configuration contains of devices, queues and RIPs.
Devices are the printers and cutters as available to the account. Devices are assigned to sites, which are identified by the site serial number. Moving devices from one site to another and site management is only available in the cloud-UI. Moving devices between RIPs and set-up of the devices is available through the API.
Queues are local automated processes, that are also accessible via local hotfolders. Jobs can be send directly to the device when the are production ready and contain an imposition and print-mode. Alternatively they can be send to a queue first, who will execute the defined pre-processing steps, including creating an imposition and setting the print-mode.
RIPs are individual computers that perform the heavy weight lifting and executes all instructions in the job, renders it to the resolution and ink-set of the printer, performs color management and encodes to the format accepted by the device.
Automation describes the cloud based workflow and nesting, thus before assigning it to a device or site. The cloud based automation allows to define JIT-nesting and job processing.
The REST calls are made over HTTP to api.aurelon.com in all regions besides China, where api.aurelon.cn is to be used. To authenticate the calling application specific headers are required. Information about the authentication can be found in the chapter Authentication.
Feedback on the status of jobs and devices after they have been created using the REST API are send using a WebSocket server. After opening a WebSocket connection your application can subscribe to the events its want to receive and will get those events through this channel.