Video Generation API

Integrate the BetterToken video API in the user's application.
Read BETTERTOKEN_API_KEY only from the environment; never log or send it to analytics.
Base: https://bettertoken.ai/v1
Request JSON (replace the I2V source with your own accessible image):
{
  "model": "wan-3.0",
  "operation": "text_to_video",
  "prompt": "A rainy city street at night, slow forward camera move",
  "duration": {
    "mode": "fixed",
    "seconds": 5
  },
  "output": {
    "format": "mp4",
    "resolution": "480p",
    "aspect_ratio": "16:9"
  },
  "audio": {
    "mode": "on"
  }
}
H3 and WAN 2.7 generate native audio by default with no on/off switch. When switching model, adapt resolution, operation, aspect ratio, media and audio. Kling uses provider_options.kling.mode, without output.resolution. H3 image_to_video requires adaptive; reference_to_video allows adaptive or a fixed ratio. WAN 2.7 I2V requires a first frame and omits aspect_ratio.
POST /videos/quote with the same JSON for a non-reserving estimate; requires authentication and may probe input media. It is not a public guest API.
BEFORE POST /videos persist an Idempotency-Key and exact body outside the process; load that saved state after a restart. Persist the task ID after acceptance and resume that task. After a timeout/503 or uncertain acceptance, reuse BOTH; never create a replacement task. Handle 409 video_idempotency_conflict / video_acceptance_pending, 402 balance and 422 validation errors.
202 means accepted only; response has root id/status. GET /videos/{id} every 5 seconds: queued, in_progress, completed, failed, canceled. Uncertain acceptance stays in_progress with stage=reconciliation. On 429 honor the full Retry-After seconds or HTTP date. Poll up to 360 times, waiting 5 seconds between requests; network delays and rate-limit backoff can extend the total observation time. Preserve the task ID when stopping; stopping does not cancel or recreate the task.
Only after completed, GET /videos/{id}/content with an authorized owner key. 410 video_artifact_expired is a delivery expiry, not a generation failure. Keep content private.
Inspect billing separately: confirmed failed/canceled generation releases/refunds the original funding source through financial processing; status alone does not prove the refund is committed. Uncertain acceptance and post-generation delivery failures need separate handling. Do not invent a public cancel endpoint.