The details that quietly ruin photo pipelines
Four things go wrong in almost every photo-to-PDF pipeline. All four are handled by default here.
EXIF orientation. Rotate the pixels first, then strip the metadata. Otherwise every landscape photo ends up sideways.
Progressive JPEG. Invalid inside a PDF. We emit baseline unless you ask otherwise.
Display P3. iPhones shoot in a wide gamut. Without an explicit conversion to sRGB, colours come out washed out or oversaturated.
HEIC. Detected from magic bytes and decoded properly, instead of failing on a file that looks fine on the phone.
One call instead of two hundred and fifty
curl https://api.justapi.tech/v1/image/batch \
-H "Authorization: Bearer ak_live_..." \
-d '{"images":[{"url":"...","ref":"photo_01"}],"options":{"width":1600,"max_bytes":250000}}'
Up to 250 images per call, processed in parallel across the provider pool, with per-image failures that do not take down the batch. There is no batch surcharge: you pay the same as 250 individual calls and save 249 round trips.
Drop-in URL transforms
If you already serve images through a transform URL, the pattern is the same shape:
https://img.justapi.tech/t/{key_id}/w_1200,q_76,f_jpg/{file_id}
Cached at the edge, so the second request for the same transform is a cache hit and costs nothing.