Re-render an existing sprite from a different camera viewpoint while keeping the same character and pose, taking a source image (URL or base64), a required camera_rotation azimuth (one of 0, 45, 90, 135, 180, -135, -90, -45 degrees), an optional camera_elevation (0, 30, or 60 degrees; omit to keep the current elevation), and an optional n (1-4) for the number of variations. Only works with sprite image types (not icons, screenshots, etc.). Synchronous until September 10, 2026: the call blocks and returns an array of rotate-sprite results, each with the generated image url and the camera_rotation and camera_elevation that were applied. Credits are charged only on success, scaled by the number of images generated. Use this to produce alternate view angles of a character; use generatePose instead to change the character's pose rather than the camera, and animateSprite or transferMotion to bring a sprite to life. Pass an optional request_id to tag the results so you can retrieve them later via `GET /assets/sprites/results`. Requires an API key (user scope). Async is the intended integration pattern: pass `async: true` and the call returns 202 with a job id - poll `GET /assets/jobs/{id}` (`getApiJob` in MCP), honouring poll_after_ms or long-polling with wait=30, until status is succeeded, whose result field is exactly the response documented for this operation. Synchronous responses are deprecated: they remain the default until September 10, 2026, after which requests default to async and return 202 with a job id; set `async: false` explicitly to keep synchronous behavior during and after the transition. 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).