Kling motion control with avatar_id instead of image_url

Yes: on POST /v1/kling/3.0/motion-control you can send avatar_id or avatar_handle in place of image_url. Sume's schema asks for exactly one visual source, and says a ready avatar is resolved server-side to the avatar's identity still, so you do not pass a picture URL at all.

Which visual source fields are allowed?

Three fields name the still: image_url, avatar_id, avatar_handle. Each description says it is mutually exclusive with the others, so a request carries one of them plus the required motion_video_url and duration_seconds.

The same pattern is used by the MiniMax H3 Max lip-sync body, so one avatar can feed both a motion clip and a talking clip.

When is an avatar the better source?

When the same person has to appear across many clips and you do not want to host and re-check a still each time. The avatar is resolved on Sume's side, so your request holds an id, not a file.

If you only have a one-off photo, image_url is simpler. It has to be a public HTTPS URL that the service can fetch.

What error should I expect for an avatar that is not ready?

The 409 description in the OpenAPI lists stable error.code values that include avatar_handle_taken, avatar_not_ready, and idempotency_conflict. avatar_not_ready is the one to handle here: wait until the avatar is ready, then submit.

Do not resubmit under a new idempotency key to get around a 409. For idempotency_conflict the schema says the error details name the job that already holds the key, so adopt that job instead of creating another.

• Send exactly one of image_url, avatar_id, avatar_handle.
• Handle avatar_not_ready by waiting, not by retrying in a tight loop.
• Read the job through the status_url in the response, per Jobs and results.