Changes to Rig a 3D model: generate a skeleton and skin weights for an existing GLB so it can be animated. Accepts a URL or base64-encoded GLB in `model` (here `model` is the 3D asset file, not an AI model name - rigging has no model choice). The job result is a downloadable `model_url` for the rigged GLB. rig_type selects the skeleton prior - general (default, any asset), humanoid (anime-style characters), game (classic game-character rigs), or the pinned humanoid templates for two-armed, two-legged characters: humanoid_template (standard 22-joint skeleton with named joints) and humanoid_template_hands (52 joints, five fingers per hand). Animation presets retarget onto any rig type, though not onto every model. joint_naming relabels the identified joints to a convention - smpl (default), mixamo, humanik, unreal, godot, rigify, or vroid - without changing the skeleton. Credits are held when the job is accepted and refunded if it fails or is cancelled. Rigging is non-destructive to geometry but replaces any prior skeleton, so animations made against an old rig no longer apply. Requires an API key (user scope). The call returns 202 with a job id - poll `GET /assets/jobs/{id}`, honouring poll_after_ms or long-polling with wait=30, until status is succeeded; its result field is exactly the response documented for this operation. Synchronous responses are deprecated but still supported: pass `async: false` to block until the result is ready and receive it as the response body. Synchronous calls run on the same queue: the response carries an X-Ludo-Job-Id header, and a job still running after 15 minutes comes back as 202 with the job instead of an error. Each account may have up to 50 generations queued or running at once via the API; a request beyond that returns 429 (code PENDING_JOBS_LIMIT).