Send a product photo and a short note about the motion you want, and get a video clip back as a file. Your script repeats that for every item in a catalog, using the same video models and the same credits you can test in the toolkit today, with a key you create in your account.
A catalog of product photos is too long to animate by hand. An image to video API lets your own code do the repetitive part: you send a photo and a short description of the motion, a video model returns a clip, and a script repeats that for every row in your spreadsheet. Picasso IA's API works that way, with a key from your account and the same models you can test in the toolkit today.
Most shops already have the hard part done: a clean photo of every item. What they lack is motion, because product pages, social ads and marketplace listings increasingly want a short clip, and nobody has time to open a web app and upload photo number 400. For ten items a browser is fine. For a catalog it is a loop, and loops belong in code.
With the API you create a key in your account, send one request per generation that names a model and its inputs, and the result comes back as a file you can download. The video side of the catalog is large: 121 of the 502 models sit in the text-to-video category, and several of them accept a starting photo. You can browse them in the full catalog. The toolkit runs the same models today, so you can try any photo and any model there before you write a line of code, and the same choices carry over to your script.
Image-to-video models do not behave alike. Some hold the first and last frame exactly, some add sound, some are better at a slow product turn than at a person walking through a scene. Run the same photo through two or three of them in the toolkit, keep the one that respects your product, and write that choice into your script.
| Model | What it does with your photo | Reach for it when |
|---|---|---|
| wan-2.7-i2v | Animates one photo, can pin the first and last frame, accepts an audio file | You want a clean turn that starts and ends on the exact shot |
| kling-v3-video | Starts from a photo, can pin an end image, optional generated sound, longer clips | Something in a lifestyle scene has to move |
| ray-3.2 | Photo as the opening or closing frame, loop option, HDR output | A looping background for a product page |
| veo-3.1 | Photo as the starting point, reference images to keep a subject consistent, sound on by default | A product placed in a setting with ambient audio |
Settings differ model by model, including clip length, resolution and aspect ratio, and the list moves as models are added. Check the model page in the catalog for what a given model accepts instead of assuming it matches another one.
Try one photo in the toolkit first, then move the same choices into code. The path through the API is short, and every step stays at the level of what you would do by hand.
The photo already says what the product looks like, so the prompt should only say what moves. Describe one camera move and at most one other change: a slow orbit around the bottle, steam rising from the cup, fabric lifting in a light breeze. Long prompts invite the model to improvise, and improvisation is how a three-button jacket grows a fourth button.
Write the prompt as a template with a slot for the item: the product name, one motion phrase and one lighting phrase. Keep the motion phrase the same across a category, so all the mugs move like mugs and you can spot the outlier at a glance.
Reuse one wording for a whole category and change only the product name. When one clip looks wrong, you know it is the photo or the model, not a prompt you rewrote halfway through the batch.
Pin the end frame when the model allows it and the clip must finish on the clean hero shot. Ask for no text on the product, because lettering is exactly what these models bend first.
Photo choice matters as much as the prompt. A sharp, evenly lit shot on a plain background gives the model less to guess about, while a cluttered scene with reflections gives it plenty. Crop so the product fills most of the frame, keep the edges clear of hands and props, and avoid photos where a label is half hidden: whatever the model cannot see, it makes up.
A batch is your loop plus some bookkeeping. Read the photo list, send one request per item, save each returned file under the item's own identifier, and write down which model and which prompt made it. That record is what lets you regenerate one clip next month without redoing the rest.
Start with a small sample of products that cover your hardest cases: glossy surfaces, thin straps, anything with printed text. Review those clips, fix the prompt template, and only then let the loop run on everything. Every generation costs credits that depend on the model and the settings, so a sample run is also the cheapest way to learn what a full run will spend; the pricing page is where plans live.
If what you actually need is a handful of clips for ads rather than a pipeline, the walkthrough on product demo videos and the page on turning photos into videos cover the same models without any code.
A script removes the typing, not the judgment. Five places where it stops helping:
Platforms also set their own rules for video length, format and disclosure. Check the current requirements of each marketplace or ad network before you upload a batch.
It is a way to ask for a video from code instead of from a web page. Your script sends a photo, a model name and a short prompt, and the generated clip comes back as a file. In practice it is the same job you do in the toolkit, repeated automatically, which is what makes it useful for a catalog with hundreds of items.
Yes. You create a key in your account, and it ties each request to you and to your credits. Treat it like a password: do not paste it into a public repository, a shared document or code that runs in a visitor's browser. If you think it leaked, create a new one and stop using the old one.
Several in the catalog accept a starting photo. The ones this page focuses on are kling-v3-video, wan-2.7-i2v, ray-3.2 and veo-3.1, and they differ in how they treat the first and last frame, sound, loops and clip length. The video category holds 121 models in total, so test two or three on your own photos before you pick one.
Yes, and it is the sensible order. The toolkit runs the same catalog today: pick a model, attach a product photo, write a short prompt and generate. Once a model and a prompt keep your product faithful, you know exactly what your script should send. New accounts get free credits, enough to compare a few models on a few photos.
Generations are paid in credits, and the cost depends on the model and the settings you choose, so there is no single price per clip. Video costs more than a still image. Look at the pricing page for the plans, and run a small sample of your own photos first to see what a full catalog would spend before you start the loop.
You send one request per generation, so a catalog is a loop in your code, one request per photo. That keeps each clip separate, which helps because a failed or poor result affects only that item. Run a small sample first, check the clips, then run the rest, and keep a record of the model and prompt used for each file.
Longer than an image, and it varies with the model and the settings, so no honest figure fits every case. Your code should wait for each result instead of assuming it is ready, and it should not depend on all clips finishing together. Plan batches as a job that runs in the background and gets collected later.
Only if the photo is yours to use. Photos you took or commissioned are fine; supplier images, marketplace listings and anything from a stock site depend on their license, so read it first. Skip photos with a real, identifiable person unless you have their permission, and keep the animation truthful about the item you are selling.
Not always. Models invent motion, and invented motion can bend a logo, change a color or add a detail the item does not have. That is why every clip needs a review before it goes live. Short prompts that describe only the motion, plus a pinned end frame where the model supports it, reduce the drift but do not remove it.
Check the model's page in the catalog first, because each model accepts different inputs and a request that suits one can be rejected by another. If that does not solve it, ask support and describe the model, the photo and what came back. Testing the same photo in the toolkit often shows whether the problem is the input or the request.
Ready to see your own product move? Open the toolkit, run one photo through a model, and use what you learn as the template for your script.
Choose your language
