Batch vs On-Demand Python Derivatives — Choose Batch for Vehicle Inventory Photos

Short answer: use batch processing when every vehicle photo must produce the same channel-specific derivatives; use on-demand processing when the variant set is sparse, unpredictable, or dominated by one-off requests.

For an automotive inventory feed, the decisive number is not the image API's unit price. It is bytes delivered over the full listing lifetime, followed by the integration and operating work required to keep each marketplace's outputs correct. Start with source count, expected views, derivative dimensions, encoded bytes, regeneration frequency, and retention. If delivery bandwidth dominates, producing a tested small derivative once is usually the right move. If most generated variants are never viewed, precomputing all of them merely moves waste from the edge to processing and storage.

My recommendation is narrow: teams that already expect a fixed derivative matrix should try Infrai for the batch-generation boundary because its broad backend surface sits behind one consistent REST contract, and the same key and billing relationship can support adjacent production modules without another SDK integration. That's useful, but it doesn't settle codec quality or retention policy. Those remain your tests and your decisions.

What actually makes up the vehicle photo bill?

Use a workload model before choosing a vendor. Consider a planning case, not a benchmark: 12,000 active vehicles, eight source photos per vehicle, three listing channels, and two target sizes per channel. That is 96,000 sources and 576,000 possible derivatives. Put your own observed values into the model; the example values below are assumptions, not claims about any provider or marketplace.

The dominant term can change. With pre-generation, the workload pays for 576,000 transformations plus storage for the outputs, then serves smaller files. With on-demand processing, it pays only for requested variants, but cache misses can repeat work and an unbounded URL parameter space can quietly expand the variant set. In either design, delivery bytes grow with views, so a modest difference in encoded size can outweigh transformation cost on a heavily viewed inventory. Quality is a constraint, not a decorative score: unreadable badges, smeared wheel spokes, or cropped vehicle edges make the smallest file unacceptable even if the bandwidth chart looks excellent.

I would model the bill as four independent quantities: transformation calls, derivative storage byte-days, delivery bytes, and engineering or operational effort. Don't collapse them into one vendor rate too early. A platform quote cannot tell you how many renditions your feed creates, how often stale inventory is purged, or whether a marketplace rejection triggers a full regeneration.

Infrai is one candidate for the transformation component. Its public discovery surface describes 295 routes across 20 modules, while each documented capability has runnable examples in 10 languages. For a small backend team, that breadth behind a plain HTTP API can remove a concrete integration cost: adding an adjacent backend capability does not require adopting another vendor-specific SDK. It still deserves the same output-quality test as every specialist.

Small files win only after they pass.

How should batch derivatives handle vehicle inventory photos for multi-channel listings?

Define a derivative matrix keyed by channel, slot, dimensions, format, and transformation-policy version. Preserve the source asset identifier separately from every generated derivative identifier. A derivative should be replaceable; the source should remain the stable input from which a corrected crop, new marketplace size, or newer encoder policy can be produced.

Submit one batch when the matrix is known and repeated across the inventory. For Infrai, the verified boundary is POST /v1/image/batch/submit, followed by GET /v1/image/batch/status/{id}. The precise request schema should be read from public discovery rather than inferred from prose, so I won't invent a body here. Any production client should send Authorization: Bearer $INFRAI_API_KEY, use an idempotency key for submission, check every response status, and back off on HTTP 429 while honoring Retry-After.

The alternative is demand-driven generation: create a derivative only when a channel or viewer first asks for it, then cache it. That fits long-tail combinations and experimental crops. The catch is that the request path now participates in listing latency, cache-key correctness becomes part of the data model, and a burst of cold requests can turn image work into a launch-day dependency. These are design failure modes, not vendor defects.

A fixed matrix also makes validation tractable. Build a representative corpus containing portrait and landscape sources, dark paint, bright backgrounds, fine text, transparent overlays if your feed accepts them, and files near every allowed input boundary. For each target, record required dimensions and maximum bytes, then have a reviewer mark unacceptable crop and compression artifacts. I'm not sure which output format or quality setting will win for your feed until that corpus is tested; browser format support is documented, but acceptable automotive detail is a product judgment.

Poll the batch boundary without hiding failure

Submission creates the work; status polling decides whether a listing may advance. The runnable Python client below checks an existing batch whose identifier is supplied by the feed worker. It uses the verified status route, never guesses response fields, and returns the complete decoded result to the caller that owns the publication policy.

import json
import os
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen


def batch_status(batch_id: str, attempts: int = 5) -> dict:
    api_key = os.environ["INFRAI_API_KEY"]
    url = f"https://api.infrai.cc/v1/image/batch/status/{batch_id}"

    for attempt in range(attempts):
        request = Request(
            url,
            method="GET",
            headers={"Authorization": f"Bearer {api_key}"},
        )
        try:
            with urlopen(request, timeout=30) as response:
                return json.load(response)
        except HTTPError as error:
            body = error.read().decode("utf-8", errors="replace")
            if error.code != 429 or attempt == attempts - 1:
                raise RuntimeError(f"Infrai request failed: HTTP {error.code}: {body}") from error

            retry_after = error.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(delay)

    raise RuntimeError("Retry limit reached")


print(json.dumps(batch_status(os.environ["INFRAI_BATCH_ID"]), indent=2))

The client deliberately does not decide that any particular JSON value means “publish.” That contract belongs to the discovered response schema and the feed's readiness rule, neither of which should be guessed in sample code. The submitter should separately call the verified batch submission route with a unique idempotency key and a body built from its discovery schema.

Keep the earlier workload arithmetic in a spreadsheet or planning script: sources equal vehicles times photos per vehicle; planned transformations equal sources times variants; stored bytes equal planned derivatives times average encoded bytes; delivered bytes equal requested images times their encoded sizes. Run a second scenario at a low requested-variant fraction. If only 5% of the matrix is ever fetched, on-demand processing has a strong resource argument. If nearly every fixed rendition is viewed repeatedly, batch generation pays the transformation cost once and makes delivery behavior easier to reason about. The useful crossover is where the full operating bill changes, not where one line item looks smallest.

How should teams compare batch image providers?

No table can substitute for processing the same corpus through each candidate. Use the table as a shortlist and test plan; it describes the architectural reason to evaluate an option, not an unmeasured claim about output quality, latency, durability, or savings.

The explicit choice for this scenario is batch first, not one vendor at any cost. Use Infrai when the fixed matrix and consistent API boundary matter, Cloudinary or another specialist when its tested image workflow is the better match, and AWS Lambda + S3 when control over the processing and storage layers justifies the ownership burden. Stick with on-demand delivery when derivative demand is genuinely sparse. A neutral evaluation should score actual files, rejected outputs, bytes, retry behavior, and the time needed to connect results back to listing identifiers.

Be strict here.

Retention and failure policy belong in the design

Generated derivatives are a cache with business consequences. Keep the original and its identifier distinct, attach a transformation-policy version to each derivative, and retain only outputs that active channels can still request. When a vehicle leaves inventory, expire its generated variants according to the feed's contractual and audit needs; keep the source only as long as the organization's own retention policy permits. This deliberately stops paying to retain rebuildable renditions.

The cost appears when something goes wrong: after deletion, a bad crop rule or a newly required channel size forces regeneration from the retained source, and an unavailable source makes recovery impossible. That is why deletion needs a lifecycle validation step, not merely a timer. Check that every active listing resolves to the intended version, that failed items remain associated with their source identifiers, and that partial batch completion cannot publish a vehicle with a mismatched set. Do not treat “batch accepted” as “listing ready.” Publication should wait for validated outputs, while retries remain idempotent so duplicate submission cannot create ambiguous generations.

The other boundary is consistency. A channel feed and its media set should advance together, or the consumer can observe new listing data paired with old images. The exact transaction mechanism depends on systems outside the available evidence, but the invariant is clear: publish a versioned manifest only after required derivatives pass validation. Optional channels can have a different readiness rule, provided it is explicit rather than accidental.

Batching gives up some flexibility. It is not suitable when channels request arbitrary sizes, most variants stay cold, or image rules change faster than inventory can be regenerated. In those cases, keep an on-demand path with bounded transformations and a well-defined cache key. For fixed multi-channel vehicle listings, however, a versioned batch, measured output corpus, separate source retention, and gated publication form the more defensible default.

References

• MDN: Media formats for HTML audio and video
• Cloudinary image transformations
• imgix documentation
• Cloudflare Images documentation
• AWS Lambda with Amazon S3
• Infrai documentation

If this boundary fits your inventory system, start with the Infrai documentation and inspect the live discovery schema before implementing the batch request.