The Plugin Integration API now exposes the full canonical-flow packshot lifecycle. POST /api/v1/plugin/jobs accepts an optional job_type field (default photo_shoot, enum from CG_JOB_TYPES): submissions with job_type='packshot' and auto_register_packshot=true produce a product_packshots row that lands in the catalog awaiting operator review. The existing POST /api/v1/plugin/jobs/{id}/accept|reject endpoints now cascade the vote onto the linked catalog row for packshot jobs, while non-packshot jobs continue to use voting as pure metadata. Operator-uploaded packshots via POST /api/v1/plugin/packshots are auto-approved on insert — the operator vouches for the content.
A new photo-shoot acceptance gate validates that every photo-shoot subject references an accepted packshot for its product. When the gate is enabled, plugin clients can omit packshot_asset_id on photo-shoot subjects and let the backend resolve the latest accepted packshot from product_ref; explicit packshot_asset_id values are still honored but validated against the same-product / accepted-state requirement. The gate is rolled out gradually — global env flag PLUGIN_PHOTO_SHOOT_GATE_ENABLED defaults to off so existing integrations keep working, and super-admins can opt individual accounts in via POST /api/admin/plugin/accounts/{id}/photo-shoot-gate-toggle. Once the flag flips on globally, photo-shoot submissions without an accepted packshot will return HTTP 422 packshot_not_approved — plugin operators should adopt the explicit packshot stage before that cutover. Webhook job.completed payloads now include job.job_type so plugin back-office surfaces can route packshot completions to a review queue.