Runway's API bills a rejected generation the same as a finished one

The shot

Runway, a video-generation company best known for its consumer web app, publishes a separate application programming interface, or API, that lets an outside pipeline request a generation directly from code rather than through a browser. The company's developer documentation describes credit-based, per-second pricing across several models and sets out moderation and rate-limit rules specific to programmatic use, distinct from the terms a single person clicking through the consumer site would see.

What the documents show

Runway's own API pricing guide states each generation run through the API 'costs credits,' purchasable at a fixed rate, and lists per-second credit costs that vary by model and output resolution. This is the company's own documented pricing structure, not an independent cost analysis. A separate moderation page states the API evaluates 'all elements of your request,' including images and text prompts, and that 'moderated generations have the same credit cost as successful generations' — meaning a rejected request is still billed. The company's production launch guidance describes usage governed by tiers and recommends testing for '429 Too Many Requests' and '503 Service Unavailable' responses before relying on the API in a live pipeline, which is the vendor's own description of expected failure conditions rather than a published numeric rate limit.

The workflow

A visual-effects or production pipeline integrating the API would request an API key, choose a tier sized to expected daily generation volume, and call the API from its own render or asset-management software rather than a browser session. Runway's documentation recommends storing that key in a secrets manager rather than hard-coding it, issuing separate keys per environment or developer, and monitoring error rates, request counts, and throttled task counts once the integration is live. Content still passes through the same automated moderation applied to consumer requests, so a pipeline needs its own handling for a moderated or failed generation rather than assuming every request succeeds.

What the tool does not change

The documentation does not describe the API judging whether a generated asset is usable in a shot; that remains a downstream review step in whatever pipeline calls it. Charging the same credits for a moderated, failed request means a studio's own budget planning has to account for rejected attempts, not just successful ones. The company's own guidance to avoid hard-coding a key and to monitor account suspension risk from repeated moderation failures both describe operational discipline the studio must build itself.

• What is the studio's own fallback when a generation returns a moderation failure mid-shot?
• How does the chosen usage tier compare to the pipeline's actual expected daily generation volume?
• Who inside the pipeline reviews a successful API generation before it is treated as a finished asset?

Read against the company's own documentation, the API is best understood as a metered, rate-limited service layer with its own cost and failure model, not a drop-in replacement for a human decision about whether a given generated shot belongs in the cut.