Skip to content

Server Contracts

FastVideo's typed public API (fastvideo.api) is consumed by three server-class integrations that must share one execution substrate so we don't grow three near-duplicate progress loops:

Consumer Transport Request shape State model
Stateless OpenAI HTTP POST /v1/videos VideoGenerationsRequest → GenerationRequest merged onto ServeConfig.default_request Stateless; optional ContinuationState round-trip
Streaming WebSocket WebSocket JSON + binary fMP4 GenerationRequest per segment Server-held SessionStore, snapshot-on-demand
Dynamo native backend Dynamo RPC NvCreateVideoRequest → adapter → GenerationRequest Aggregated today; disaggregated via ContinuationState later

All three consume the same underlying surface:

from fastvideo import VideoGenerator
from fastvideo.api import (
    ContinuationState,
    GenerationRequest,
    InputConfig,
    OutputConfig,
    SamplingConfig,
    ServeConfig,
)

# Sync today, async after PR 7.10 lands VideoGenerator.generate_async.
result = generator.generate(request)

These docs lock down the request/response shapes so drift between FastVideo, the internal UI, and Dynamo can be caught at review time. PR 8 does not ship runtime code; it ships the contract reference and the contract tests that guard it.