avatar-1.0/image-to-video is deprecated: switch to veed/fabric-1.0

POST /v1/avatar-1.0/image-to-video is a deprecated, still-supported alias; the correct call is POST /v1/veed/fabric-1.0. The same goes for POST /v1/models/sume/avatar-1.0/image-to-video/runs, which maps to POST /v1/models/veed/fabric-1.0/runs. Both aliases keep accepting the same body, so migrating is a URL change.

This is from the Fabric alias migration section of the Sume models overview.

What body does the Fabric route take?

Send audio_url, a measured duration_seconds, and exactly one visual source: either image_url or avatar_handle. They are mutually exclusive. The docs prefer image_url of a generated, inspected posed still, and say to use avatar_handle only when the user named that avatar. Media URLs must be public HTTPS, as described in Media inputs.

curl -X POST https://api.sume.com/v1/veed/fabric-1.0 \
  -H "Authorization: Bearer $SUME_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: fabric-host-001" \
  -d '{
    "image_url": "https://example.com/host-still.png",
    "audio_url": "https://example.com/line.mp3",
    "duration_seconds": 8
  }'

How does this differ from the Avatar 1.0 talking video?

Why is a talking face never a plain video clip with narration?

The docs state that video models do not lip-sync to generated TTS or to a later voice-over, so an on-camera speaking shot is a still plus audio through Fabric, while wordless beats and product motion use the video models. If you were using the old image-to-video alias for that, nothing about the behavior changes; only the model id in the URL does. The same still-plus-audio shape exists as MiniMax H3 Max lip sync, whose audio runs 5 to 14.8 seconds.

What about MCP?

With MCP the same body lives inside payload on the supported avatar-image-to-video_create tool. The tool name keeps its old prefix even though the model id is veed/fabric-1.0.

What should I check in my own integration?

Look for the old path in your code, your scheduled jobs and any agent prompt that names it. If you call through MCP, the tool name stays avatar-image-to-video_create, so there is nothing to rename there. Confirm that you send duration_seconds measured from the audio you are sending, not a guess, since Fabric expects the measured value.

Also confirm that you only send one visual source. Sending both image_url and avatar_handle breaks the rule that they are mutually exclusive.

Why keep an alias at all?

The docs mention that existing live-commerce integrations can migrate by changing only the URL, which is why the old routes were kept. Deprecated here means the docs steer new work elsewhere; it does not mean the route has been switched off. If you are starting fresh, use the Fabric route; if you are maintaining something older, move it when convenient and test with one request.