Give the people who use your app a way to type a prompt or attach a picture and get a finished clip back, without leaving your product. This page covers the product questions that decide whether the feature works: the wait, the credits, moderation, storage and rights.
Your users already know what a short clip is. What they do not have is a way to make one inside your app without hopping to another tab and coming back with a file. With the Picasso IA API, your app sends one request per generation, naming a video model and its inputs, and the finished clip comes back as a file you can show, store and review. The request is the easy part. The product around it is the real work: the wait, the credits, the moderation, the storage and the rights.
A video feature changes what your product is for. A greeting card app that can animate the card, a travel journal that turns a photo into a moving postcard, a game tool that makes a short intro for a character, a store dashboard that drafts a product clip: in each case the user stays where their work already lives instead of exporting, converting and importing.
The other reason is choice. The Picasso IA catalog holds 502 models, and 121 of them are in the text-to-video category, with another 28 in video editing. That matters for a builder because no single video model is best at everything. One handles a human subject well, another follows a camera instruction closely, another is the cheaper option for a draft. The API is meant to reach the same catalog as the toolkit and the same credit system, so you are not locking your feature to one engine's habits.
The honest framing: this is a way to offer generation, not a way to guarantee outcomes. Every clip your users create is a model interpreting a prompt, and your product has to be designed around that fact, not in spite of it.
Before any architecture, write down the three or four things a person does in your feature. Most video features collapse into the same small set of actions, and naming them early keeps the interface honest.
The first is text to video: the user describes a scene and a motion in a sentence or two and gets a clip. The second is image to video: the user attaches a picture they own, such as a product photo, a drawing or a portrait of themselves, and asks for it to move. The third is a retry: the first clip is close but wrong, so they change one word and generate again. The fourth, if your product needs it, is a small edit afterwards, like trimming, upscaling or adding sound, which other models in the catalog cover. If you want a feel for the second action, turn photos into videos walks through it in the toolkit.
Nothing in that list needs the user to know which model ran. You can expose a picker or choose for them.
Five concerns decide whether a video feature feels solid or frustrating. None of them is a coding problem, and each one has a version the user can see. This table is the planning sheet: what the user experiences, and the decision that is yours to make.
| Concern | What your user experiences | The decision that is yours |
|---|---|---|
| Wait time | A clip is not instant, so the screen needs a state for it | Show progress, let them leave and come back, or notify them |
| Credits | Each generation costs credits that depend on the model and settings | Pass the cost on, absorb it, or cap how many clips a person can make |
| Moderation | Some prompts or pictures should never become a clip | Filter inputs, review outputs, and decide what a report does |
| Storage | The returned file has to live somewhere they can find it again | Where it is kept, for how long, and who may delete it |
| Rights | The clip may show a face, a voice or a design that belongs to someone | Require that people upload only their own material or fictional subjects |
Wait time deserves the most design attention, because it is the thing users feel. Generation takes real time, and it varies with the model and the settings, so build for a range instead of a number. A user who can keep using your app while a clip works will forgive a long wait.
Credits are the other quiet one. The cost comes from the model and the settings picked, and the pricing page is where the plans live. Decide early whether your users see credits at all, because it changes your interface: an app that spends your credits on their behalf needs limits, and an app that passes them through needs a clear price before the click.
Design rule: treat the clip as a result that arrives later, not as an answer you wait for. If your screen only works when the response is fast, it will fail the first time a model is slow.
You can run most of this loop today without writing anything, because the toolkit runs the same catalog the API is meant to expose. Use it to decide what your feature should ask users for, then wire up the same shape in your app.
Run step one with a dozen real prompts before step three. Prompts a stranger types are where your moderation decisions come from.
You do not need to settle on one model for the whole feature. Think in roles, test a few in the toolkit and pick per use case. These are models that exist in the catalog today, all in the text-to-video category, which also holds the image-to-video variants.
For a premium result on a hero moment, start with veo-3.1 from google or kling-v3-video from kwaivgi. For short, playful clips, seedance-2.0 from bytedance and hailuo-2.3 from minimax are worth a run. wan-3 from alibaba and sora-2 from openai round out a first comparison, and ltx-2.3-fast from lightricks is the name to try when you want to see how a lighter model behaves for drafts.
Do not read that as a ranking. Run the same three prompts through each, look at faces, hands, motion and how well the prompt was followed, and write down which model wins which job. If your product turns still pictures into clips, the AI product demo videos page shows what a product shot needs to survive animation. Browse the full list in the catalog before you commit to a shortlist.
A generation API gives you clips. It does not give you a video product. These are the limits to plan around, so none of them arrives as a surprise after launch.
None of this argues against the feature. It argues for scoping it: short clips, a clear waiting state, visible credits and a review step. A small feature that behaves predictably beats a big one that surprises people.
That is the purpose of the Picasso IA API. Your server sends one request per clip, naming a model and its inputs, and the result comes back as a file you can download and show inside your own screens. Your users never see another site. What they will notice is the wait, since a clip takes time to generate, so the experience depends on a good in-progress state more than on anything else you build.
Yes. Access works with a key you create in your account, and it should be handled like a password. Keep it on your server, load it from a secret store or environment setting, and never put it in a mobile app, a browser bundle or a public repository. If you think it leaked, replace it from your account and update your server. Your users never need to see it.
The catalog has 121 text-to-video models and 28 video-editing models, out of 502 in total, and the toolkit runs all of them today. Names worth testing first include veo-3.1, kling-v3-video, seedance-2.0, hailuo-2.3, wan-3 and sora-2. Check the model pages for what each one accepts, since some take only a prompt and others can start from a picture. Run your own prompts in the toolkit before choosing.
It depends on the model, the length and the settings, so this page quotes no number. Plan for a range: some clips will come back quickly and others will take noticeably longer. The safe design is to confirm the request immediately, show that work is in progress, let the person keep using your app and notify them when the file is ready. Test your chosen models in the toolkit to feel the real waits.
Generation costs credits, and the amount depends on the model and the settings chosen. The API is meant to use the same credit system as the toolkit, so what you see there is what to expect. Plans and their allowances live on the pricing page, and new accounts get free credits to test with. You decide whether to absorb the cost, pass it to your users or cap how many clips each person can make.
Two places: what comes in and what comes out. For inputs, decide which prompts and uploaded pictures you refuse, such as images of real people who have not agreed to appear. For outputs, review clips before they are shared publicly, since models can produce odd or unwanted results. Give users a way to report a clip and decide what happens next. Your own terms of use should say all of this plainly.
The result comes back as a file you can download, so keeping it is up to you. Save it in storage you control, tied to the user who asked for it, and decide how long it stays and who can delete it. Do not rely on the returned file staying available forever. If clips may be shared, plan access rules from the start.
Check two things. First, the rights to the input: a user who uploads their own product photo is in a different position from one who uploads someone else's artwork, and the generator does not change who owns what a picture shows. Second, the terms attached to your plan for outputs. Put your own rules in front of users, and have a qualified person review them if clips will be sold or published commercially.
Only of themselves, of someone who has clearly agreed, or of a fictional character. Never a real identifiable person without consent, and never a minor's photo uploaded by someone else. Build that into your upload screen with a short plain line, and into your terms. A clear rule beats a clever filter.
Plan for both. Wrong clips are normal: let users edit the prompt and try again, and show the credit cost of a retry before they press the button. Failed requests need a clear message and a way to try again. If something looks broken on your side or you have a question about your account, support is the direct route to a person.
A good way to start is to test the clips your users would ask for. Open the toolkit, run a few real prompts through two or three video models and write down what your feature needs to promise.
Choose your language
