Async Tasks

Method	Path	Use
`POST`	`/v1/content_generation/tasks`	Create a generic async content generation task (image / video / ...)
`GET`	`/v1/content_generation/tasks/{task_id}`	Poll a generic content generation task
`DELETE`	`/v1/content_generation/tasks/{task_id}`	Cancel an unfinished task and release its preauthorization (upstream-dependent — see "Cancel a task" in Seedance Video Inbound Protocol)

/v1/content_generation/tasks is a more general async task entrypoint than the standard OpenAI-compatible video flow. It covers image, video, and other generation capabilities that must run as backend tasks.

Create a task

The body follows the upstream generic generation shape and must include at least model:

bash

curl https://api.modelgo.ai/v1/content_generation/tasks \
  -H "Authorization: Bearer $MODELGO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"doubao-seedance-2.0-mini","content":[{"type":"text","text":"a red apple on a table"}]}'

On create, the response has status=queued and an id such as gw_…; polling the same id ended at succeeded with resolution=720p, ratio=16:9, duration=5. The same model on POST /v1/video/generations is model_protocol_not_offered. DELETE cancel returned provider_unsupported on that upstream.

Poll a task

bash

curl https://api.modelgo.ai/v1/content_generation/tasks/task_123 \
  -H "Authorization: Bearer $MODELGO_API_KEY"

Create and poll both answer with the same Ark-shaped task object, regardless of which upstream served the request:

json

{
  "id": "task_123",
  "model": "<model>",
  "status": "succeeded",
  "created_at": 1756600000,
  "updated_at": 1756600120,
  "content": { "video_url": "https://.../video.mp4" },
  "usage": { "completion_tokens": 123, "total_tokens": 123 },
  "error": null,
  "resolution": "1080p",
  "ratio": "16:9",
  "duration": 5
}

status is one of queued / running / succeeded / failed; id is the gateway task id, and it is the only id polling and cancelling accept.

Three spellings, one pipeline

The same managed async pipeline has three inbound spellings. Which one you pick depends only on whose payload style you want to write your client against:

Entry point	Request body	Response body
`/v1/content_generation/tasks`	Generic generation shape	Ark task object (above)
`/ark/api/v3/contents/generations/tasks`	Ark content-generation native body	Ark task object
`/minimax/v2/video_generation`	MiniMax video-generation V2 native body	MiniMax shapes (`{"task_id"}` / `{"task":{…}}`)

Billing, task persistence, artifact delivery, and preauthorize/settle behave identically across all three.

When to use it

The platform capability is asynchronous but does not use the OpenAI Video-standard request / response shape
You want a unified platform-managed create-and-poll flow instead of handling each vendor's native protocol yourself
You are calling a video model such as Jimeng that is exposed only through the managed async lane

Key conventions

model is still the platform logical model name; the platform decides which upstream implementation handles the task.
Request fields depend on the routed capability; the response shape, by contrast, is fixed — see above.
If you do not want to manage multiple vendor-specific polling styles, prefer this entrypoint.

For the standard OpenAI-compatible video protocol, see OpenAI-Compatible Video Flow.