How to Automate Product Images with Webhooks and Picnie

The manual version does not survive a real catalog

Removing a background, resizing to a marketplace spec, and compressing one product photo takes a couple of minutes by hand. Doing that for every new SKU, every restock photo, and every reshoot - for as long as the store exists - is not a task a person should keep doing manually. A webhook is what turns "please remember to do this" into "this simply happens."

What a webhook is actually doing here

A webhook is a small HTTP notification one system sends to another the moment something happens - a product created in your store, a new file landing in cloud storage, a status change in your PIM. Instead of a person noticing that event and manually starting an image job, the event itself carries the trigger: this SKU's photo is ready, go process it.

Push, not poll

The alternative to a webhook is polling - checking every few minutes whether anything new appeared. Polling wastes requests checking for nothing most of the time and adds delay before it notices anything. A webhook fires exactly when the event happens, with no lag and no wasted checking.

Anatomy of a webhook-triggered image pipeline

1. A new product photo lands in your store, PIM, or a watched storage folder.
2. That system fires a webhook containing the image URL and useful metadata like SKU or product ID.
3. Your middleware or automation tool receives the webhook and calls the relevant Picnie step - background removal, resize to marketplace spec, compression.
4. The processed image URL is written back to the product record or PDP.
5. Optionally, a notification confirms the job completed, or flags it for review if something looks off.

A concrete example: new SKU, finished image, no person involved

A merchandiser uploads a raw studio photo for a new SKU. A webhook fires the moment that file lands. The pipeline removes the background for a clean white-background primary image, resizes to the marketplace's required dimensions, and compresses for a fast PDP - then writes the final URL back to the product listing. By the time the merchandiser checks the listing, the processing step has already happened.

Webhooks, polling, or a manual button - choosing between them

• Use webhooks when the source system supports them and volume is more than occasional - this is the default for anything catalog-scale
• Use polling only when the source system genuinely has no webhook support and near-real-time is not required
• Keep a manual trigger available for exceptions - a reshoot, a one-off lifestyle image - so not everything has to fit the automated happy path

Watching the pipeline, not just building it

An automated pipeline that silently fails is worse than a manual process, because no one notices until a listing has a broken image for two weeks. Log every job, alert on failures rather than successes, and periodically spot-check output the same way you would QA a batch run - automation removes repetitive work, not the need for oversight.

Handling images that fail automated processing

Not every product photo behaves - a busy background confuses cutout detection, a low-resolution phone snap does not survive resize cleanly, a corrupted upload never makes it through the pipeline at all. An automated flow needs an explicit path for these cases rather than assuming every input will succeed: route failures to a review queue instead of a dead end, flag the specific SKU rather than the whole batch, and let a person handle the exception manually while the rest of the catalog processes normally. It also pays to log the reason a job failed, not just that it failed - a resize failure and a corrupted-upload failure need completely different fixes, and a queue that only says "error" forces someone to re-investigate from scratch every time. A pipeline that silently drops failed images is far more dangerous than one that occasionally asks a human to look at something.

Setting this up

Start from Picnie integrations to see the available connection points, and pair them with the API reference if your store or PIM needs a custom webhook receiver rather than a pre-built connector. For catalog-specific context on why this matters for ecommerce teams specifically, see Picnie for Ecommerce.