Overview/OpenAPI/Explainer Video

Explainer Video

Create, manage, edit, and export flows organized around explainer video use cases.

Explainer Video API

This page explains the API from the perspective of the Explainer Video family.

There are three public video types:

  • explainer_video
  • slides_video
  • vector_animation

Legacy compatibility:

  • knowledge_video is still accepted as an input alias
  • catalog and API responses now use explainer_video

Start With Type Mapping

If your product accepts natural-language requests, add a mapping layer from user wording to OpenAPI type first:

Public label OpenAPI type Best for Common trigger wording
Explainer Video explainer_video polished short videos, explainers, narrated final pieces explainer video, 讲解视频, 解说视频
Explainer Video (Slide-based) slides_video step-by-step explanation, PPT-style structure, training or classroom breakdowns illustrated, PPT video, slide-based video, 课件视频
Vector Animation vector_animation process, structure, mechanism, and principle explanation vector animation, flow animation, mechanism animation

Requests that only say explainer video / 讲解视频 usually start with explainer_video. Switch to slides_video only when the request clearly wants an illustrated, step-by-step, PPT-like format.

Minimal Create Requests

The core endpoint is still:

POST /creations

Most common fields:

Field Meaning
type explainer_video / slides_video / vector_animation
prompt what the user wants to explain
language output language
aspect_ratio such as 16:9 or 9:16
voice_id optional, load valid values from /catalog
style_id optional, load valid values from /catalog
duration_seconds currently supported only by explainer_video
scene_count currently supported by slides_video; slide_deck uses it too

explainer_video

{  "type": "explainer_video",  "prompt": "Create a 30-second explainer video that explains MCP clearly",  "language": "en",  "aspect_ratio": "16:9",  "duration_seconds": 30}

slides_video

{  "type": "slides_video",  "prompt": "Create a PPT video that explains MCP step by step in 6 pages",  "language": "en",  "aspect_ratio": "16:9",  "scene_count": 6}

vector_animation

{  "type": "vector_animation",  "prompt": "Use vector animation to explain the MCP request flow",  "language": "en",  "aspect_ratio": "16:9"}

Do not send duration_seconds for vector_animation, and do not reuse scene_count for explainer_video. Supported durations, page counts, voices, styles, aspect ratios, and quality levels should always come from /catalog.

Standard Read Flow After Creation

The common management flow is:

  1. GET /creations/jobs/{job_id}
  2. GET /creations/{creation_id}
  3. GET /creations

The usual priorities are:

  • status
  • progress_pct
  • current_step
  • main_url
  • artifacts[]
  • scenes[]

Edit

Video workflows are where scene editing matters most.

Endpoint:

POST /creations/{creation_id}/edit

Typical actions:

  • update_scene_narration
  • regenerate_scene

If you need scene-level rewrites, narration changes, or single-scene regeneration, keep working from the existing creation_id instead of starting a fresh create request.

Export And Result Reads

Prefer the assets already returned in the detail response. Do not guess export links.

explainer_video / vector_animation

These should primarily be treated as video exports:

  • main_url
  • subtitle assets
  • scene-level media

slides_video

Explainer Video (Slide-based) can provide additional document exports besides the video itself:

  • PPT
  • PDF

If the detail response already includes those document exports, use them directly. Do not invent another export-trigger layer unless the API explicitly requires it.

Practical Guidance

  • define the user wording to type mapping before implementing create logic
  • treat explainer_video / vector_animation as video-first workflows, and add document exports only for slides_video
  • /catalog is not optional; limits and enum-like values should all come from it