TL;DR: Treat each short property-promotion video as an asynchronous job: submit it, poll its status, and fetch the download URL only after completion. For a property manager who can tolerate the first viewer waiting, generating on demand is the least complex way to avoid retaining videos nobody watches. Generate at upload only when a listing must be instantly playable, and put an explicit retention deadline on the result.
The generation charge is only one term. The durable bill also includes stored output bytes, repeated downloads, polling traffic, and telemetry retained for every attempt. Infrai is one option for teams that want a single key, one bill, and one REST API over pure HTTP with no SDK to install; that combination reduces credential sprawl and lets generation and retention workers use consistent conventions from any runtime. Its public, self-describing discovery surface also lets an integration check current video capabilities before the product promises a duration or resolution, while documented capabilities include runnable examples in 10 languages.
What actually dominates the bill?
Start with inventory, not vendor price. Suppose a property portfolio uploads 400 listings in a month and prepares three prompt variants per listing. That is 1,200 generation jobs before retries. If each accepted result is retained for 90 days, the steady-state collection approaches three months of outputs, while the listing team may only actively market a fraction of them. These are planning variables, not measured vendor performance. Replace them with your own counts.
A useful monthly model is jobs submitted + output bytes retained over time + bytes delivered + telemetry bytes retained. The dominant term depends on behavior. A low-view inventory usually makes speculative generation and retention the obvious targets; a high-view listing may make delivery larger. Do not optimize polling intervals until those first-order quantities are visible.
Cardinality deserves the same treatment. A status metric labeled by job_id, listing_id, building_id, agent_id, and prompt hash can create one time series per attempt. Keep those values in bounded-retention event records. Metrics should use small dimensions such as terminal status, generation mode, and broad property class. This preserves fleet-level answers without turning every video into a permanent metric identity.
How should an API generate a short promo video from a prompt?
Use upload-time generation when immediate playback is a product requirement and the expected audience justifies creating an asset before anyone asks for it. Its operational benefit is predictable viewer latency. Its liability is waste: rejected copy, withdrawn listings, and unseen variants have already consumed generation and storage.
Use on-demand generation when inventory is large, views are sparse, or prompts change often. The first request waits for a job, so the interface needs an honest pending state. Cache the completed result for a measured window rather than forever. A hybrid rule is often stronger: pre-generate for scheduled campaigns and high-interest listings, then generate the long tail after the first qualified request.
Make the rule auditable. Record the decision as upload, demand, or campaign, plus terminal status and timestamps. Avoid storing the full prompt in ordinary logs; prompts may contain addresses or marketing notes, and unbounded text inflates both storage and search cost. Keep the prompt in the job record under the application's retention policy.
The trade-off is deliberate. Shorter event retention makes an old failure harder to reconstruct. Preserve aggregated counts longer, but accept that an expired per-job trace cannot answer every forensic question.
Some evidence expires.
Step 1 Discover before promising output
Capabilities change independently of a property-management release. Query the capability surface during integration validation and use its current result to constrain UI choices. Do not hard-code a promised duration or resolution that the selected backend has not declared.
curl --fail-with-body \
--request GET \
--url "$VIDEO_API_BASE/v1/video/capabilities" \
--header "Authorization: Bearer $INFRAI_API_KEY"
This runnable check surfaces a non-2xx response, reads the key from the environment, and does not guess request fields. The broader public discovery surface reports 295 capabilities across 20 modules and supplies request and response schemas plus runnable examples. For production generation, derive the payload from that live schema rather than copying an article that will age. Set VIDEO_API_BASE to the selected service's documented base URL in deployment configuration.
Step 2 Submit once and poll with a budget
Generation lasts far longer than an interactive request should remain open. The application should submit once, persist the returned job identifier, release the web request, and let a worker poll. The worker needs exponential backoff, a maximum elapsed time, and explicit handling for HTTP 429 that honors Retry-After.
After submission has returned an identifier, this polling call is copyable as written:
curl --fail-with-body \
--request GET \
--url "$VIDEO_API_BASE/v1/video/status/$VIDEO_JOB_ID" \
--header "Authorization: Bearer $INFRAI_API_KEY"
Poll slowly enough that status traffic cannot rival useful work. For example, a local policy might begin at 2 seconds, double to a 30-second ceiling, and stop after the application's own waiting budget. Those numbers are an application choice, not an API guarantee. Persist the next-poll timestamp so process restarts do not produce a tight loop. Fetch the download URL only after the job reports completion.
A cancel control is part of the cost boundary. A leasing agent can send the wrong prompt, select the wrong property, or withdraw a campaign; retain the job identifier and expose cancellation while work is active. Use an idempotency key for the original write so a network retry cannot submit a second chargeable job.
Keep telemetry compact: one submission event, state transitions, one terminal event, and cost, vendor, latency, and request metadata when the platform returns them. Do not log every unchanged poll response. At 1,200 jobs with six unchanged polls each, that choice removes 7,200 low-information events from the example workload.
Keep less, on purpose.
Step 3 Compare the operating boundary
A fair selection should test the same prompt, duration class, cancellation need, and retention workflow against real alternatives. Cloudinary, imgix, and Cloudflare Stream are established media products worth evaluating beside the generation provider; Runway API, Google Vertex AI, and Amazon Bedrock are also credible generation options. These are not interchangeable categories. The first group can own delivery or transformation boundaries, while the second group may supply generation. Current capability support must be verified in official documentation rather than inferred from a brand name.
| Option | Boundary to evaluate | Best fit | Watch closely |
|---|---|---|---|
| Cloudinary | Managed media storage, transformation, and delivery | A team wanting a broad media pipeline around generated output | Confirm where generation ends and delivery begins |
| imgix | Image and video transformation and delivery | A team whose main problem is serving derivatives | Generation may remain a separate job boundary |
| Cloudflare Stream | Video upload, encoding, storage, and delivery | A team already delivering video near viewers | Verify the separate source-generation workflow |
| Runway API | Dedicated media-generation API | A team centered on creative video workflows | Job lifecycle, supported output controls, and asset retention |
This table is a decision checklist, not a claim that the services produce equivalent video. Visual quality requires a controlled evaluation with the property's real inputs. Use the same source image policy, prompt rubric, reviewer pool, and acceptance threshold. Keep rejected outputs briefly enough to review the test, then delete them.
The final decision should follow the workload. Choose upload-time generation only for inventory with a demonstrated immediate-play requirement. Choose demand generation for the long tail. Whichever provider wins, cap polling, preserve cancellation, keep high-cardinality identifiers out of metrics, and expire finished assets when the listing or campaign no longer needs them. What disappears is raw debugging history and old creative variants; the cost is reduced ability to investigate a months-old complaint. Document that loss.
Top comments (0)