File and media input, output, and lifecycle

Beginner: four input methods

A URL fits an object already in storage. Base64 or a data URL fits a small one-off input. Multipart fits file forms such as transcription and image editing. An upstream Files API fits reusable uploads only when explicitly supported. The gateway /v1/files routes return not implemented, so an uploaded file ID cannot be assumed to work across models.

Prepare the site address and API key before running the transcription example:

Copyexport BASE_URL="https://api.tu-zi.com"
export API_KEY="your site API key"

Copycurl "$BASE_URL/v1/audio/transcriptions"   -H "Authorization: Bearer $API_KEY"   -F "model=gpt-4o-mini-transcribe"   -F "file=@sample.mp3"

Confirm the audio endpoint in the marketplace and follow the selected protocol for fields, MIME type, and format.

Support belongs to the endpoint

Chat vision may accept a remote or data URL. Image editing often uses multipart or a reference-image field. Transcription uses multipart. Video can use an image URL or a provider asset ID. Never copy a file_id, URL, or field from one successful protocol into another. Base64 magnifies payload, logging, and memory risks.

URL input security

Before server-side fetching, require HTTPS, resolve DNS, and reject loopback, private, link-local, and cloud metadata addresses. Repeat validation after every redirect. Bound redirects, connection and read timeouts, response bytes, and content type; a MIME header is not a substitute for magic-byte validation. Do not give an upstream provider a credential-bearing intranet URL.

Upload and memory

Stream multipart data, enforce request and per-file limits, and reject unsupported formats early. Do not load a large video into memory in one call. Temporary files need unguessable names, least privilege, and deterministic cleanup. Log size, digest, MIME, and object ID rather than full Base64 data or signed URLs.

Result lifecycle

A synchronous response may contain Base64 or a short-lived URL; an async task can return a binary result envelope. Validate status, type, length, and digest before streaming to owned storage. Delivery is complete only after the durable business copy succeeds. An expired or 410 download URL should not be retried forever.

Expert governance

Define data classes, allowed formats, malware scanning, decompression and image-bomb protection, tenant isolation, and deletion propagation. Record upstream provider, region, retention policy, task ID, and deletion time. Capacity planning must cover bandwidth, temporary disk, object storage, concurrent connections, and Base64 expansion—not only request count.

MiniMax M3: upload a video and reference its URL

POST /v1/media/video is a gateway extension using the existing H3 staging object store. Authenticate with a site API key and send exactly two multipart fields: model and file. Supported models are MiniMax-M3.1-Flash and MiniMax-M3; the token must have model access and an available channel. MP4, MOV, AVI and MKV signatures are accepted, with a 50,000,000-byte file limit. Codec compatibility is still determined by upstream processing.

The response contains url, bytes, mime_type and delete_token. Use url in messages[].content[].video_url.url in a chat request. This is video understanding input, separate from H3 video generation. It does not create a MiniMax file_id or mm_file:// reference and does not offer the larger Files API limit. Existing public video URLs can be sent directly to chat completions.

Administrators must enable publicly reachable staging storage with deletion support and configure a stable encryption key. Anyone holding the URL can fetch the media; it is not a user-authenticated private download. Retention follows the storage lifecycle configuration, without a guaranteed expiry from this API. Keep the deletion receipt secure and delete the object after all inference requests finish. Deletion requires a valid site token, the same user and application identity, and the receipt; renewed model access is not required. Retry deletion with the same receipt on failure. Changing storage profiles or encryption keys may affect old receipts, so clean up objects first. Deleting an object does not purge CDN caches or copies already downloaded.

Upload and deletion share a per-user limit of 10 requests per minute. Each process accepts up to four simultaneous uploads; 30 seconds without request-body data triggers a timeout. Video inference uses normal model usage billing; uploading does not consume model token quota.

Copyexport BASE_URL="https://api.tu-zi.com"
export API_KEY="YOUR_SITE_API_KEY"
# Requires curl and jq. Keep upload.json private: it contains the deletion receipt.
umask 077
curl --fail-with-body "$BASE_URL/v1/media/video" \
  -H "Authorization: Bearer $API_KEY" \
  -F "model=MiniMax-M3.1-Flash" -F "file=@sample.mp4" > upload.json

jq -n --arg url "$(jq -r .url upload.json)" \
  '{model:"MiniMax-M3.1-Flash",max_tokens:512,messages:[{role:"user",content:[{type:"text",text:"Describe this video."},{type:"video_url",video_url:{url:$url}}]}]}' \
  > chat.json
curl --fail-with-body "$BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  --data-binary @chat.json

# Delete only after all requests using the URL have finished.
jq '{delete_token}' upload.json > delete.json
curl --fail-with-body "$BASE_URL/v1/media/video/delete" \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  --data-binary @delete.json