2026-10-02

POST /v1/avatar-1.0/fabric is test-only: use veed/fabric-1.0 instead

The experimental avatar-1.0/fabric route is a temporary comparison endpoint that may be removed. How it differs from image-to-video and what to build on.

5 min readSume

All posts

POST /v1/avatar-1.0/fabric is a temporary, test-only route, and Sume's docs say not to build production integrations on it. For talking clips from a still plus audio, call POST /v1/veed/fabric-1.0, whose public model id is veed/fabric-1.0.

Everything here is from the Models overview, read 2026-10-02. It matters because the path looks like part of the Avatar 1.0 family, and a copied curl command could land you on it.

What is the experimental route for?

The docs describe sume/avatar-1.0/fabric as a route used to compare a different talking-clip backend against POST /v1/veed/fabric-1.0 on identical inputs. It takes the same request body, so a comparison script only has to swap the path.

That is a Sume-internal comparison tool exposed for testing. It is not a product feature, and it carries no promise of a stable contract.

How does it differ from the supported path?

The docs compare it with the older image-to-video alias, which maps to the same supported talking-clip route.

image-to-video versus experimental fabric (read 2026-10-02)
	image-to-video	avatar-1.0/fabric (experimental)
duration_seconds	1 to 300	1 to 15, rounded up; over 15 rejected
speed_tier	Selects a provider speed tier	Accepted and ignored
Price	$0.1875 per second at 720p	$0.3024 per second at 720p

Why should I not build on it?

The page gives three reasons. The name fabric is placeholder test branding that will change before general availability. The route may be changed or removed outright once the comparison finishes. And veed/fabric-1.0 stays the supported path for talking clips, including Live Commerce and the MCP tools.

At about 1.6 times the per-second price and a 15 second cap, it is also the worse deal for real work. A comparison script is the one legitimate use.

What should I call instead?

Send audio_url, a measured duration_seconds and exactly one visual source: an image_url of the generated, inspected still, or an avatar_handle when the user named that avatar. The two visual fields are mutually exclusive.

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-clip-001" \
  -d '{"image_url":"https://example.com/host.png","audio_url":"https://media.sume.com/artifacts/host.wav","duration_seconds":8}'

The audio URL above is a placeholder; use a real file you hold. For the deprecated aliases and the one-line migration, see the deprecated-route post.

Where does this fit against script-driven avatar videos?

POST /v1/avatar-1.0/talking-video is the script-driven path: you send text and an avatar handle, and Sume handles the voice. The Fabric route is for when you already have the audio and a still. Video models do not lip-sync to generated speech laid underneath, so a talking face comes from one of these two routes.

Check the public API page for the table of supported routes before you wire anything in.

How do I check which route my code calls?

Search your repository for /avatar-1.0/fabric. Any hit outside a comparison script is a bug to fix before general availability changes the name. Also search for /avatar-1.0/image-to-video, which still works as a deprecated alias but should move to /v1/veed/fabric-1.0; both aliases keep accepting the same body, so the migration is a URL change.

If you only have the MCP tools, the supported talking-clip tool is avatar-image-to-video_create, with the same body inside payload. Use the tool, not a hand-built URL, and the route naming never reaches your code.

Finally, keep clips over 15 seconds off any experimental path by habit. The supported route accepts 1 to 300 seconds, so there is no reason to split work to fit a test route's cap.