Skip to main content
GET
Get a signed download URL for a motion's 3D animation extraction
Only meaningful for a Motion created with type glb or all, or generated from text via POST /v1/motions with application/json; a render-only Motion has nothing to export. This replaces the old, now-removed GET /v1/animations/{animation_id}. download_type selects the file format — glb or fbx — not a skeleton. Every request resolves all three rig variants at once for that format: mixamo_url, metahuman_url, and metahuman_body_url. All three rigs, in both formats, are always generated up front from the same pass, so switching download_type on the same motion_id never triggers new work or waits on a regeneration. GLB works with Mixamo, MetaHuman, and other Unity-compatible animation workflows; FBX is the same rigs/animation baked as FBX files, for pipelines (Unreal, Blender, Maya, etc.) that expect that format instead.
Choosing a rig. mixamo_url is a general-purpose, 50-joint rig used across Mixamo, Unity, Unreal, and most DCC tools; it normally needs retargeting onto your own character mesh. For a Viggle vsplat Character, metahuman_url is the 441-joint full rig corresponding to joint_set=full, while metahuman_body_url is the 86-joint body-only rig corresponding to joint_set=body. Motion export currently has no dedicated 119-joint output for joint_set=expression.

Request parameters

Response parameters

Returns 200 OK. All three URL fields are always present in the response — unlike a design where each rig has its own download_type value, there’s nothing here that’s conditionally omitted. A rig that isn’t ready yet (or doesn’t apply) simply stays null rather than causing an error; it’s never dropped from the response.
Request fbx for the same Motion instead — no regeneration needed, and the same three fields carry FBX URLs this time:
Omitting download_type (status check only) returns all three URL fields as null:

Examples

Download URLs are short-lived and re-signed on every read — request download_type again rather than caching the URL.
download_type values other than glb or fbx answer 400 INVALID_REQUEST — “invalid download_type”.

Next step

A text-generated Motion has no 2D render counterpart — only this export applies. A video-sourced glb/all Motion also keeps its video_render capability; use Render Video (from Character and/or Motion) with motion_id for that side once it’s ready.

Authorizations

Authorization
string
header
required

Server-side SDK clients use a project API key. Remote MCP clients use an OAuth access token. Never expose a project API key in browser code.

Headers

X-Request-Id
string

Optional caller-supplied correlation ID, up to 128 characters. The service returns the effective value in the response header for tracing and support.

Required string length: 1 - 128
X-Viggle-Source
string

Optional source-channel label, up to 128 characters, used to attribute traffic to an SDK, integration, product surface, or internal workflow.

Required string length: 1 - 128

Path Parameters

motion_id
string
required

Public Motion ID returned by motion creation or listing. It normally begins with mot_ and must identify a Motion owned by the caller.

Minimum string length: 1

Query Parameters

download_type
enum<string>

Selects the pre-generated file format to return as signed URLs: glb or fbx. All three rig variants (mixamo_url, metahuman_url, metahuman_body_url) for that format come back together.

Available options:
glb,
fbx

Response

Current animation export state.

A motion's 3D animation extraction (video source) or generation (text source), for download. download_type selects the file format — glb or fbx — not a skeleton; each request resolves all three rig variants for that format at once (mixamo_url, metahuman_url, metahuman_body_url). All three rigs, in both formats, are generated up front from the same underlying pass, so switching download_type never triggers new work or a wait. The three URL fields are always present in the response — a rig that isn't ready yet simply stays null rather than being omitted or erroring. Download URLs are short-lived and re-signed on every read. Formerly AnimationResource, returned by the now-removed GET /v1/animations/{animation_id}.

id
string
required

ID of the Motion whose 3D animation export is represented.

Minimum string length: 1
status
enum<string>
required

Current lifecycle of the 3D animation extraction or generation. Download only when this is ready and the relevant rig URL is populated.

Available options:
queued,
processing,
ready,
failed,
cancelled
download_type
enum<string> | null
required

Echoes the requested download_type — the file format shared by mixamo_url/metahuman_url/metahuman_body_url below.

Available options:
glb,
fbx,
null
mixamo_url
string | null
required

Short-lived signed URL for the Mixamo rig in the requested download_type format, once ready; otherwise null. Always present, regardless of which format (or none) was requested.

metahuman_url
string | null
required

Short-lived signed URL for the 441-joint MetaHuman rig (full facial) in the requested download_type format, once ready; otherwise null. Always present.

metahuman_body_url
string | null
required

Short-lived signed URL for the 86-joint body-only MetaHuman rig in the requested download_type format, once ready; otherwise null. Always present.

thumbnail_url
string | null
required

Reserved for response-shape compatibility and always null because Motion animation exports do not generate thumbnails.

created_at
string | null
required

ISO 8601 timestamp with a UTC offset. May be an empty string on a task that has not recorded one.

updated_at
string | null
required

ISO 8601 timestamp with a UTC offset for the latest 3D animation state update; null if unavailable.

error
object | null
required

Structured extraction or generation failure when status is failed; otherwise null.