Automatic image analysis for plugin packshots

Plugin API packshots are now automatically analyzed for product context so generation jobs produce higher-quality output without any extra work on the merchant side.

Every packshot registered through POST /plugin/packshots is now run through Qamera's image analyzer in the background. The analyzer extracts the side view (front, back, side, top, bottom), tells whether the photo contains text, captures the background, and infers product-level fields such as general category and characteristics. The resulting metadata is stored in the per-installation catalog and feeds into the generation prompts automatically — there is no extra API call, header, or flag to opt in.

For merchants this means visibly better generation results: side-view confusion (e.g. a back view rendered as a front shot) and lost text on packaging — the two most common failure modes — are addressed at the source. Packshots uploaded without a separate source_image_ref no longer need one; the API creates a backing source image row automatically and the same content uploaded twice is deduplicated by hash without re-analyzing.

A few behavioural changes for plugin authors to be aware of:

  • Jobs that target a packshot the plugin has not registered first will now fail with the new PLUGIN_JOB_MISSING_CATALOG_ENTRY error type. Register the packshot via POST /plugin/packshots (or an equivalent catalog mutation) before submitting jobs.
  • Two new error types — PREPARE_PHOTOS_TIMEOUT and PREPARE_PHOTOS_FAILED — may appear on webhook.failed deliveries when the analyzer takes too long or rejects an image. Both are permanent failures and surface the underlying reason in the webhook payload.
  • The optional product_name, product_specific_category, product_side, and product_general_category fields on POST /plugin/jobs body are now deprecated. The API still accepts them for backward compatibility but ignores their values — the equivalent fields from the catalog drive the prompt. The deprecation will be enforced in a future release; we recommend removing these from request bodies.

Existing integrations continue to work without code changes; the new behaviour is purely additive on the analysis side.