Background Removal in automated workflows (pre-flight)

This article shows you how to run Background Removal once on a photo before any render, so every downstream render — across multiple templates or a whole Design Group — reuses the already-processed result instead of processing the same image over again.

Why pre-flight processing matters

When a Zap or API call passes a raw photo directly into a render, Templified processes it on the spot. That's fine for a single render. But if you're fanning the same photo out to several templates at once — or sending it through a Design Group that covers a full set of products — each render job would process the same photo independently. Pre-flight processing eliminates that repetition: process once, then pass the result into as many renders as you need.

There are two practical benefits:

Speed. The cut-out is ready before renders start. Render jobs that would have waited for processing can begin immediately.
Cost. Background Removal is charged per photo processed, not per render. Processing the same photo once and reusing it means you're charged once, regardless of how many renders use it.

How it works

The pre-flight step is a separate API call — or a dedicated Zapier action — that runs Background Removal on a photo and returns the processed result. You then pass that result into your render step. When Templified sees a photo that has already been processed, it uses the cached version immediately.

Submit the photo for processing. Call POST /api/v1/photos/process with the photo's URL. In Zapier, use the Background Removal action.
Wait for the result. Processing typically takes 10–17 seconds. The API can return the result inline (add ?sync=true to the request) or respond immediately with a job_id you poll with GET /api/v1/photos/process/:job_id. The Zapier action handles polling for you automatically.
Use the processed URL in your render. The completed job returns an extracted_url — the cut-out image. Pass that URL as the photo field value in your POST /api/v1/create or Design Group render call. Templified recognizes it as already processed and skips re-processing.

A Zapier Zap showing a Background Removal step feeding its Extracted Image URL output into a Create Image step

API quick reference

The minimal request to process a photo with background removal:

POST /api/v1/photos/process
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

{
  "image_url": "https://example.com/raw-photo.jpg",
  "remove_background": true
}

A complete result looks like:

{
  "job_id": "ph_clx...",
  "status": "complete",
  "extracted_url": "https://cdn.templified.io/uploads/org/extracted.png",
  "content_hash": "ab12cd34..."
}

Pass extracted_url as the photo field value in your next render call. The content_hash is how Templified identifies that the photo has already been processed — reusing the same URL or hash guarantees no double-processing.

To block inline and get the result in a single response (suitable for small batches and workflows where Zapier's timeout isn't a concern), append ?sync=true:

POST /api/v1/photos/process?sync=true

For larger batches or if the sync window elapses, poll the poll_url returned in the 202 response until status is complete.

Zapier workflow

In Zapier, insert a Background Removal action step before your Create Image step. Map the Extracted Image URL output of the Background Removal step to the photo field in the Create Image step.

The action polls automatically; your Zap moves on as soon as the result arrives.

Design Groups and fan-out

Design Groups render multiple templates from a single call. Each template that includes a photo slot will receive the same photo. Pre-flighting the photo before calling POST /api/v1/design-groups/create ensures every template in the group gets the already-processed cut-out — no re-processing for each member.

The pattern is the same: process the photo first, then pass the extracted_url as the field value in your batch render request.

Reuse across repeated renders

Once a photo has been processed — whether through the pre-flight endpoint, a Zapier action, or the Remove BG button in Studio — the result is cached. Any subsequent render using the same photo URL reuses the cached cut-out instantly and without an additional charge. You only pay for processing when it actually runs on a photo for the first time.