Print File Handling

print file handling — api reference for external integrators overview purple dam now supports print ready file variants (psd, tiff, ai, eps, indd) alongside standard web images editors can upload these files directly or attach them to existing online images only psd and tiff files are automatically converted into a web friendly image (webp, with jpeg fallback) for use in online articles; other formats (ai, eps, indd) cannot be converted and use a placeholder as the online image instead in all cases, the original print file is preserved and exposed via the rest api as a separate variant this document describes the resulting api field and how a client (e g an indesign plugin) should consume it this entire feature is behind a feature toggle it only exists on a given hub if explicitly enabled for that hub; where it is not enabled, the api and media behavior are unchanged from today, and the print image field will not appear at all background print formats such as psd/tiff were previously classified with generic mime types (e g application/octet stream) and treated as media type "file" rather than images, making them undiscoverable through image specific queries the new print image field solves this by exposing print files with their correct, format specific mime type (e g image/vnd adobe photoshop) through the standard image endpoint — no separate endpoint or mime type workaround required endpoint no new endpoint is introduced the print variant is exposed as an additional field on the standard wordpress media endpoint get /wp json/wp/v2/media/{id} example bash curl https //example com/wp json/wp/v2/media/41 api field print image every image object returned by the rest api now includes a print image object in addition to the existing online file data (webp/png/jpeg, etc ) the field is only populated when print image handling is enabled on the dam side (settings → purple dam → filters → enable print images) if the feature is disabled, media responses are unchanged from today's behavior field type description exists boolean whether a print variant is attached to this image id integer id of the print file present only when exists is true url string download url of the original print file present only when exists is true mime type string correct mime type of the print file, e g image/vnd adobe photoshop present only when exists is true filename string original filename of the print file present only when exists is true filesize integer file size in bytes present only when exists is true example image with a print variant json "print image" { "exists" true, "id" 46, "url" "http //example com/uploads/datei psd", "mime type" "image/vnd adobe photoshop", "filename" "datei psd", "filesize" 1926287 } example image without a print variant json "print image" { "exists" false } required client behavior when placing an image, the client should check whether print image exists is true if true, download and place the file at print image url, using print image mime type to handle the format correctly if false, fall back to the standard online image file as before — no change in behavior needed no changes to the existing online image workflow are required beyond this check supported print formats currently psd, tiff, ai, eps, indd — each returned with its correct native mime type (e g image/vnd adobe photoshop for psd) planned extension standard image formats (jpeg, gif, etc ) will also get print file handling when such an image is uploaded above the resolution threshold used for online downscaling (default 2560px), a downscaled version will be created for online use, and the original high resolution upload will become its print image — the same mechanism already used for psd/tiff clients should not assume print image only appears for the current print specific formats upload path (for reference) print files can reach the dam in two ways attached to an existing web image via the media library (recommended workflow) uploaded directly (e g a print file sent from indesign via a plugin) for psd and tiff, the dam automatically converts the file to a web image (webp, jpeg fallback, max 1920 px width, 85% quality) and attaches the original as its print image if conversion fails, the upload fails with an explicit error rather than producing an empty or broken image — clients should surface that error rather than retry silently for formats that cannot be converted (ai, eps, indd), a placeholder is used as the online image and the original file is attached as print image planned upload size limit up to 100 mb per print file notes automatic conversion to a web image (webp, max 1920 px, 85% quality, jpeg fallback) only happens for psd and tiff other print formats (ai, eps, indd) use a placeholder as the online image, since they cannot be converted print files are never exposed as browser renderable images, so there is no risk of them being inserted directly into online articles the media library additionally offers filtering by print variant status (all / with print variant / without print variant) and visual indicators for images with print variants, though this is editor facing and not part of the api contract the whole feature is gated behind a toggle per hub installation, so integrators should always check print image exists rather than assuming the field is present status & outlook the print image field is live in the current purple dam plugin and deployed to dev/staging and demo environments for integration testing the underlying implementation is expected to evolve in a future purple dam version the print image field contract described here is intended to remain stable across that migration, but integrators should expect a follow up notice if anything changes a planned improvement will keep an image mime type on the underlying psd/tiff asset itself (instead of it flipping to a generic "file" type), so uploaded and transformed assets stay linked as the same object a further planned extension will apply the same print file mechanism to standard image formats (jpeg, gif, etc ) that exceed the online downscaling threshold, not just psd/tiff/ai/eps/indd please confirm whether the described print image check can be implemented on your side, and flag any concerns before general rollout