Print assets

A print asset is a file or collection of files representing the content that will be printed as a physical product. Print assets are either PDF files or images (JPEG, PNG).

PDFs

A PDF Print asset is created with guts (interior) and cover files. Guts and cover PDF files must not exceed 2 GB in size (combined). Smaller files are recommended as they are processed faster.

PDF files must be publicly accessible through HTTP(S). We strongly recommend using Amazon S3 pre-signed URLs in the us-west-2 region.

When hosting files or using a different service be aware files will be downloaded using HTTP range requests (if your server supports them), which may result in several concurrent requests to the source files in a short time period. Unless you opt for Print API to keep a copy of your source files, they need to be available until the order has been successfully delivered because print asset files might be re-processed in some exceptional cases.

A print asset's files (including the copied original inputs, where applicable) are kept by RPI for a period of 60 days. This is so that the files will be available if needed (for example for reprints if a recipient receives a damaged book).

In case the original files will not be copied and kept by Print API, they should (ideally) also be available for these 60 days, because occasionally re-rendering of source files is required when reprinting an order.

Processing print assets can take a long time. Smaller files usually process in 10s of seconds while larger files can take a few minutes. In extremely rare cases when system load is very high your print assets could be put into a queue and it could take many minutes before processing completes.

Because many of the operations are fairly slow, the primary integration mechanism is webhooks (HTTP callbacks to your server).

If webhooks are not used, there is support for polling for status as well. The data delivered is the same, regardless of the method used. Polling makes sense for cases which involve displaying progress to the end user. In all other cases, notifications are much easier to use and more robust as well. If there is both a need for displaying progress and some backend continuation of the process, it is recommended that a notification is set up for the backend, and polling is only used for displaying progress.