MiniMax H3
Video
MiniMax H3
POST
MiniMax H3
The parameters and usage align with the official documentation. For detailed parameters, refer directly to the official documentation.
Here
You can also pass a single image without a
Please save this ID and use it to call the query endpoint. The task ID is the only identifier for subsequently querying the task status and obtaining the result.
The query endpoint can only query tasks created within the last 7 days (UTC time window [T-7d, T)); a
A polling interval of 10 to 30 seconds is recommended, and it can be adjusted according to your business scenario. Do not call the query endpoint at a high frequency.
By source video:
The
Use
The HTTP error body here is different from a queried asynchronous failed task: HTTP error details are in the top-level
1. Overview
This document describes how to call the MiniMax H3 (overseas edition) native video generation protocol, including request parameters, task queries, and billing rules. MiniMax H3 is an asynchronous video generation endpoint: after a task is submitted, a task ID is returned, and the client obtains the task status through the query endpoint. Once the task succeeds,content.url in the response is the address of the generated result.
The parameters and usage align with the official documentation. For detailed parameters, refer directly to the official documentation.
1.1 Endpoints
The overseas edition of MiniMax H3 includes three capabilities. Each has its own creation endpoint, and they share a single query endpoint:
All three capabilities share the same query endpoint:
{api_domain} is the API domain provided to you by the platform, and {task_id} is the task ID returned by the creation endpoint. task.task_type in the query response distinguishes the capability (generation, regeneration, or h3_context_ir).
1.2 Authentication
All requests must carry the platform API Key; POST requests that create tasks must also specify the JSON content type:1.3 Supported models
Themodel in the request body determines which model is used. Available values are as follows:
The two models share the same endpoint addresses, authentication method, request structure, and query structure. They differ only in the
model value, the supported resolutions, and the number of free input images.
1.4 Billing
MiniMax H3 is billed by actual generation usage, and no fee is deducted in advance when a task is submitted:
MiniMax-H3 uses different price tiers for 768P / 2K, and MiniMax-H3-Max uses different price tiers for 480P / 768P. The exact unit price depends on the overseas-edition entry on the pricing page of your platform. Failed or cancelled tasks do not incur a successful-generation fee.
1.5 Billing and usage field mapping
After each successful generation, the response’susage returns the usage of this request. The fee depends only on the seconds / image count in it, priced in tiers by video resolution (768P / 2K for H3, 480P / 768P for H3-Max); token-related fields do not participate in billing. The table below uses MiniMax-H3 as an example and explains each field; the rules for MiniMax-H3-Max are the same, except that the number of free input images is 2. The fields are explained as follows:
Billing formula: fee per item = resolution unit price × usage; fee for this request = sum of all billed items. The video resolution can be viewed in the
task.resolution field of the query response. Settlement is done once after the task succeeds; failed or cancelled tasks are not billed.
2. Create a video generation task
2.1 Request example: text-to-video
Text-to-video requires a text prompt and a non-adaptive aspect ratio:2.2 Request example: first-frame-to-video
role, in which case it is treated as the first frame.
2.3 Request example: reference-material-to-video
Reference images, videos, and audio use their corresponding roles:2.4 Request fields
2.5 Content combination rules
2.6 Input material limits
The total size of a single request body must not exceed 64 MB. Base64 increases the data size by about 33%, so larger materials should preferentially use a public URL ormm_file://{file_id}.
2.7 Create response
A successful creation returns a task ID:3. Query task
3.1 Query example
task_id outside this window returns invalid task_id.
3.2 In-progress response
When the task isqueued or running, wait and continue querying:
3.3 Success response
content.url is the address of the generated result. This download URL has an expiration time, so download it or save it to your own storage promptly; after it expires, query the task again to obtain a new URL.
3.4 Failure and cancellation responses
status may be:
3.5 Query response fields
The fields of thetask object are as follows. Some fields may not be returned depending on the status; the output of a successful task is in content, and the error of a failed task is in error.
The
usage fields of video tasks are as follows; some fields may not be returned when there is no corresponding input.
4. Video regeneration
Video regeneration regenerates a source video that already meets the MiniMax-H3 768P specification into 2K. It uses a dedicated creation endpoint,model is still MiniMax-H3, resolution is fixed to 2K, and it shares the query endpoint in section 3; task.task_type is regeneration in the query response.
4.1 Request examples
The two input methods are mutually exclusive: you cannot provide both, and you cannot provide neither:- By source task ID: pass
source_task_id, i.e., the ID of a previously successful/v2/video_generationtask (it must belong to the same account, have statussucceeded, and still be within the 7-day query window). - By source video: pass
content, which must contain exactly one source video item withtype=video_urlandrole=base_video, and re-submit the other inputs used to generate that 768P video.
text in content must be the prompt that was actually ultimately sent to the model, and must not be the original prompt before H3-Context-IR processing.
4.2 Request fields
callback_url is not supported. The source video (768P output) must contain an audio track, have a frame rate of 24 fps, width and height both multiples of 32, an area between 768×768 and 768×1344, and a total frame count of 107 to 362 frames (about 4 to 15 seconds). A single request body must not exceed 64 MB; for larger materials, use a public URL or mm_file://{file_id}.
A successful creation returns a task ID. Then poll and query according to section 3; after the task succeeds, obtain the 2K video from task.content.url.
4.3 Billing
Video regeneration is billed by the duration of the final generated 2K video and includes both the output and input parts, both charged at that duration:
Regeneration keeps the source video duration unchanged, and the upstream returns only that duration in
output_seconds (input_seconds is 0), so the input source video item is billed by output_seconds. Settlement is done once after the task succeeds; failed or cancelled tasks are not billed. The exact unit price depends on the pricing page of your platform.
5. H3-Context-IR
H3-Context-IR rewrites the original prompt and multimodal inputs into a structured enhanced prompt for subsequent video generation, and does not produce a video. It uses a dedicated creation endpoint,model is MiniMax-H3, and it shares the query endpoint in section 3; in the query response, task.task_type is h3_context_ir and task.modality is text, and the enhanced prompt is in task.content.prompt.
5.1 Request example
5.2 Request fields
callback_url is not supported.
5.3 Response
A successful creation returns a task ID. Then poll and query according to section 3. When the task succeeds, the enhanced prompt is intask.content.prompt:
task.content.prompt as the final prompt in a video generation or video regeneration request.
5.4 Billing
H3-Context-IR is billed by tokens, with input and output priced separately, in units of one million tokens:
Settlement is done once after the task succeeds; failed or cancelled tasks are not billed. The exact unit price depends on the pricing page of your platform.
6. Python example
The following example uses the standardrequests library and does not depend on any specific SDK:
7. Common errors
7.1 HTTP error response structure
When a creation or query endpoint directly returns a non-2xx HTTP status, the response body uses the following structure. Note thaterror.http_code is a string, and request_id can be used to troubleshoot the request.
error.type, error.message, and error.http_code; asynchronous task failure details are in task.error.code and task.error.message.
Upstream business errors preserve the original error code and error message as much as possible. For failed or cancelled tasks, do not keep waiting on the same task ID; fix the request and create a new task.
8. Usage recommendations
- Persist the
task_idafter creating a task; do not rely solely on client memory. - Use a polling interval of 10 to 30 seconds for the query endpoint, and set an overall timeout on the client.
- After receiving
succeeded, downloadcontent.urlimmediately, as the download URL may expire; after it expires, query the task again to obtain a new URL. - Input material URLs must be accessible by the platform and the MiniMax overseas upstream, and must not depend on the customer’s intranet or temporary login sessions.
- Use
first_frame/last_framewhen first and last frames are needed; usereference_image,reference_video, orreference_audiowhen reference materials are needed, and do not mix the two modes.
Laatst gewijzigd op 21 oktober 2026