Video Channels and Monitoring
This page is for administrators. Client integration is documented in the Video Generation API.
Configure an account
- Create or edit an OpenAI / API Key account with the supplier's Base URL and key.
- Select Video-only and the matching upstream protocol.
- Configure supported models, public-to-upstream model mappings and group bindings.
- Set account capabilities and test each model before saving.
Video-only channels do not serve text or image requests; image-only channels do not serve text or video requests. A Base URL and model mapping alone cannot adapt protocol differences.
| Protocol | Upstream contract |
|---|---|
| OpenAI Videos JSON | JSON creation at /v1/videos. |
| OpenAI Video Generations | Creation at /v1/video/generations. |
| Cangyuan | Cangyuan field conversion and polling. |
| JiaSu (general / MiniMax H3) | Creation at /v1/video/generations, polling at /v1/videos/tasks/{id}; choose the matching variant. |
| CompShare MiniMax H3 | Creation at /minimax/v2/video_generation and its corresponding query endpoint. |
| Catcode | Creation at /v1/videos/generations, query and content endpoints. |
| Legacy OpenAI passthrough | Original response/cache behavior; use explicit adapters for new channels. |
Adapters do not guarantee access to every supplier model or feature. New protocols require server-side adapters and contract validation.
Capability limits
Set supported resolutions, minimum/maximum duration in seconds, real-person support, and maximum image/video/audio reference counts. Blank means unrestricted; zero reference count means unsupported. Duration limits are positive integers with inclusive boundaries. First/end frames count toward the image limit.
Clients declare real-person content with contains_real_person: true (real_person is an alias). Unmarked requests are ordinary requests; the gateway does not classify prompts or images. These limits apply to normal selection, sticky sessions, degraded candidates and failover. Existing tasks stay bound to their original account/protocol for polling and downloads.
Manual probes
Enter comma-separated or newline-separated models in the account form. Tests run serially and continue after a model fails. Draft accounts use current URL/key and supplier model names; saved accounts apply saved model mappings. Probes use current form capabilities and the lowest available common model/account specifications, with manual overrides when needed.
Probes incur upstream generation costs. Catalog/protocol defaults cannot guarantee the lowest price for unknown models. Pending tasks resume polling rather than creating new jobs; unresolved submissions require reconciliation.
Channel monitoring
Choose text, image or video per monitored model and configure its upstream URL/key/protocol. Media generation defaults to once per hour, configurable from 300 to 86400 seconds. The monitoring check interval is separate: intermediate checks reuse cached results or poll the existing task.
Images are checked for a decodable header and dimensions; video probes fetch the first 64 KiB and check MP4/WebM container signatures. This confirms recognizable media, not full playback or content quality. Video latency includes queue/generation time. Shared PostgreSQL locks prevent concurrent paid probes across nodes.
Success rates
The admin list, user cards and model details show the last six checks and a rolling 24-hour success rate with successful/total counts. operational and degraded are successes; failed and error are failures. Fewer than six samples use the actual count; no samples display a dash. Pending jobs and repeated cached results do not add samples.
These metrics reflect monitor history, including manual backfills/edits, rather than all customer traffic. They do not apply the public availability floor.
Explicit-adapter task and replay records currently last 7 days; provider files have their own retention. Nodes must share the database and compatible task-encryption configuration. Documentation changes do not deploy the corresponding gateway features.