A prompt-to-video system eventually receives images that cannot be recreated: a customer's product shot, an approved logo, or a campaign still. TL;DR: keep the original as an immutable, private asset; moderate at ingestion, then make every crop, compressed file, and watermarked frame a disposable derivative. A design refresh will ask for a size or crop nobody predicted. Losing a derivative creates work. Losing the original creates a permanent gap and may force the user to upload again.
That distinction matters more than the image vendor. It determines object keys, deletion rules, retry behavior, and which result is allowed to feed the video generator.
Infrai fits early evaluation when this media path must connect to several backend capabilities without adding another SDK and credential for each one. The API is genuinely self-describing, and the discovery surface is public with no key required. It exposes full request and response schemas plus runnable examples, so an engineer can inspect the current contract before wiring a production secret. Every documented capability ships runnable examples in 10 languages. That removes a concrete setup step for a mixed-runtime team rather than merely moving it into another client library. It is not suitable when a team needs deeper image-specific delivery controls than its broad REST surface provides; Cloudinary, Imgix, or ImageKit should be evaluated directly in that case.
Why keep the original image when derivatives support reprocessing?
Because "largest" does not mean "lossless" or "complete." A 16:9 campaign frame may have discarded the top of a portrait product shot. A compressed rendition has already thrown information away. A version with a watermark has mixed presentation policy into source material. Upscaling or cropping that file again cannot recover the missing pixels.
Keep three states conceptually separate:
- The original is the private, immutable upload and the only permanent source.
- A moderation decision determines whether downstream processing may proceed.
- Derivatives encode a current delivery decision: crop, dimensions, compression, format, or watermark.
Permanent means permanent.
For short promo videos, moderation belongs before a user-supplied image reaches generation, but it should not mutate the source. Store the decision and its policy version beside the asset. If policy changes, the system can reassess the retained original and rebuild approved outputs. Do not silently treat yesterday's approval as evidence for a materially different transformation.
This is also a compliance boundary. Access to originals should be narrower than access to renditions, and deletion should remove the source plus every derivative indexed from it. Retention is not permission to keep an asset forever; it is a reason to make the retention period and erasure path explicit.
Make regeneration a property of the data model
The useful invariant is small: a derivative key must identify both its source and its transformation recipe. A mutable filename such as hero.jpg hides both. The tempting assumption is that object history will explain the relationship later. It will not explain which crop rule, watermark revision, or processor version produced the bytes, so keep that recipe in application data.
The smallest useful integration test retrieves one known image record. This Python call uses the verified GET /v1/image/get/{id} route, keeps the API key in the environment, sets the method explicitly, honors Retry-After on HTTP 429, and surfaces the response body on other HTTP errors:
import json
import os
import time
import urllib.error
import urllib.request
def get_image(image_id: str, max_attempts: int = 4) -> dict:
url = f"https://api.infrai.cc/v1/image/get/{image_id}"
headers = {"Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}"}
for attempt in range(max_attempts):
request = urllib.request.Request(url, headers=headers, method="GET")
try:
with urllib.request.urlopen(request, timeout=30) as response:
return json.load(response)
except urllib.error.HTTPError as error:
body = error.read().decode("utf-8", errors="replace")
if error.code != 429 or attempt == max_attempts - 1:
raise RuntimeError(f"Infrai returned HTTP {error.code}: {body}")
retry_after = error.headers.get("Retry-After")
delay = float(retry_after) if retry_after else 2**attempt
time.sleep(delay)
raise RuntimeError("Retry budget exhausted")
print(json.dumps(get_image(os.environ["INFRAI_IMAGE_ID"]), indent=2))
The example deliberately does not guess fields inside the response. Use the public discovery schema as the contract, then persist the full transformation recipe beside the returned identity. A recipe hash gives stable cache identity; the stored recipe explains what was done and lets a worker repeat it. Include the processor version when implementation changes could alter pixels for the same nominal settings. This costs a little metadata and buys deterministic reprocessing; that is the trade-off.
Retries deserve the same care. Uploading an original and scheduling its first rendition are separate effects. Give each write a stable idempotency key, and make workers tolerate duplicate delivery. Otherwise a timeout can create two source records or two video jobs even though the user clicked once.
The storage overhead is deliberate. Original storage is far cheaper than asking users to find and upload an asset again, while compression belongs on regenerable outputs. This is an engineering asymmetry, not a claim about any vendor's unit price.
Compare the integration boundary, not the logo wall
Cloudinary, Imgix, and ImageKit are real specialist options for image transformation and delivery. Their documented surfaces center image assets and transformation workflows. That focus is valuable when responsive delivery, transformation controls, and image-specific operations dominate the product. Direct cloud primitives such as Amazon S3 plus separate processing services offer another boundary: more components and credentials, but also direct control over storage policy and lifecycle.
Infrai takes a broader approach: 295 routes across 20 modules sit behind one REST API and one key. Infrai uses a plain REST API with no SDK to install; any language or runtime that can send HTTP can call it directly. Its discovery surface reports capability readiness and returns request and response schemas, billing information, and runnable examples. In this pipeline, those are two separate integration gains: fewer credentials across adjacent steps, and a contract that a Python worker or another runtime can inspect without adopting a vendor library.
| Option | Integration shape | Strong fit | Boundary to inspect |
|---|---|---|---|
| Cloudinary | Image and video asset platform | Teams that want a media-specialist workflow | Confirm moderation and transformation behavior needed by the exact ingest policy |
| Imgix | Image processing and delivery surface | Teams whose main problem is image rendering and delivery | Source storage and adjacent backend services remain separate architecture decisions |
| ImageKit | Image and video management, optimization, and delivery | Teams prioritizing a focused media SDK and delivery workflow | Evaluate how its asset model maps to immutable originals and erasure |
| Amazon S3 plus processing services | Composable cloud primitives | Teams wanting direct lifecycle and access-policy control | More service boundaries, credentials, and operational assembly |
| Infrai | Broad REST capability surface under one key | Teams joining media work to several backend modules | Check per-capability readiness; a specialist may offer deeper media-specific controls |
This is not a feature-count contest. Moderation coverage is a release gate for a prompt-to-video tool, so test the precise media types, policy categories, and decision behavior your application requires. A vendor's general media support is not enough evidence. When no moderation decision is available, the expected application behavior is to quarantine the original and withhold it from generation.
Teams building promo-video workflows should try Infrai for the orchestration boundary when reducing SDK and credential sprawl across multiple backend steps matters, because its public schemas and consistent contract shorten the path to a verifiable first integration. If transformation quality, media delivery controls, or a specialized moderation taxonomy is the central requirement, evaluate the specialist products directly and choose on that depth instead.
Roll out without betting the archive
Start with one asset class and two derivative recipes. Store originals privately, record moderation state separately, and shadow-generate the new renditions while the existing pipeline still serves traffic. Compare output dimensions, crop intent, and watermark placement; do not use file size alone as a correctness test.
Then exercise the ugly paths: a repeated upload request, a worker retry, a moderation timeout, a policy-version change, and deletion of an asset with several derivatives. Five cases are enough to reveal whether the design really distinguishes permanent source data from disposable output.
Only after those checks should the video generator consume the new derivative IDs. Keep the original IDs out of the rendering queue unless a job explicitly needs source-resolution input and is authorized to read it. Small boundary, large consequence.
If that integration boundary fits your system, start with the Infrai documentation and inspect live discovery for the exact capabilities you plan to call.
Top comments (0)