Create a key in your account, name a model in a request, and get the finished image back as a file. The same catalog that runs in the toolkit sits behind it, so catalog photos, blog covers, avatars and placeholders come from one integration instead of one account per provider.
Getting images out of code usually starts with a small mess: one account with a vendor for realistic photos, another for illustration, a third for text on images, each with its own SDK, its own key and its own idea of what a request looks like. An image generation API on Picasso IA collapses that into one key from your account and one request that names the model you want.
The cost of using several image providers is rarely the generation itself. It is everything around it: signing up, storing another secret, reading another set of docs, handling another error format, and rewriting a small wrapper every time you want to compare a new model against the one you ship today. Multiply that by a team and a roadmap and the glue code outweighs the product feature it serves.
With one key, the integration is written once. You create the key in your account, send a request that names a model and gives its inputs, and the generated file comes back for you to download. Switching from one model to another changes the model name and any settings that model offers, not the shape of your code. That is the whole pitch, and it is deliberately boring: a developer should be able to hold the entire mental model in one breath.
It runs on the same models and the same credit system as the toolkit, so a generation costs credits that depend on the model and the settings, and the pricing page is where the plans live. The catalog behind it holds 502 models in total and 212 of them are text-to-image, which is where the hundreds in the title come from. You can browse all of them in the catalog before writing a single line.
Two hundred and twelve text-to-image models is more than anyone should audition. Start with a short list that covers different jobs, run your real prompts through each, and keep the one whose output you would actually publish. These four are a reasonable first round, and each one is in the catalog today.
| Job in your project | Model to try first | What to look at |
|---|---|---|
| Blog covers and hero images | google/nano-banana-pro | Resolution options, aspect ratio match, reference images |
| Catalog and product-style images | bytedance/seedream-5-pro | Detail at the larger size, behavior with reference photos |
| Graphics with readable text | openai/gpt-image-2.5-flare | Lettering, transparent background option, quality setting |
| Print-size or large-format assets | recraft-ai/recraft-v4.1-pro | Largest output size, long detailed prompts |
| Cheap placeholders for a staging site | Any model at its lowest quality setting | Cost per image against how fast you can review the result |
The table is a starting point, not a ranking. Models differ in taste: one leans photographic, another leans illustrated, another follows a long brief more literally. The only honest benchmark is your own prompt on your own subject, judged by someone who knows what the page needs. The collection groups the catalog by category if you want to see what else sits next to these four.
The path from idea to file is short, and the order matters: prove the prompt by hand first, then automate it. Nothing here needs more than an account and a prompt you care about, and the models named above are the ones to start with.
The brief for most image calls is plain: a picture is missing and a person would take too long to supply it. A few jobs account for most of the demand, and they have different tolerances for imperfection.
Catalog images come first. A shop with a few hundred items needs a consistent look more than it needs a masterpiece, so the pattern is one fixed prompt template, filled in per item, run through one model. For items that exist, the picture must stay truthful about the item, so use generation for backgrounds and lifestyle scenes and keep real product photos where accuracy matters. The product photography page goes deeper on that line.
Blog covers are the easiest win. A script reads a post title, builds a prompt from it, and saves a cover at the aspect ratio your theme expects. Avatars for new accounts work the same way, with one rule: generate fictional characters, never a real identifiable person. The avatars page covers styles that work. Placeholders fill the gaps in a staging site or a design review, where being cheap and quick to review matters more than being polished.
A prompt typed by hand gets a second look; a prompt filled by a script does not. Write templates that stay specific when the variable parts change: fix the style, lighting and framing in the template, and let only the subject move. Say what must not appear. Keep each template short enough that you can read the whole thing and predict the output.
Run every new template against ten varied inputs in the toolkit before it goes anywhere near a loop. A prompt that works for your best example and fails for your worst one is the one that will ship a bad image at three in the morning.
Log the model name, the prompt and the settings next to every saved file. When a client asks why one product looks different from the rest, that log is the difference between a fix and a guess. If you need text inside the image, pick a model known for readable lettering and still proofread the result, since long or unusual strings can come out wrong on any model.
A single key does not remove the hard parts of generating images. Here is where it stops:
The honest summary is that the API removes integration work, not editorial work. Someone still decides what ships.
It is a way to request images from code instead of from a web page. You send a request that names a model and gives its inputs, mainly the prompt, and you get the generated image back as a file. On Picasso IA the key comes from your account and the models are the same ones that run in the toolkit, so you can try a prompt by hand and then repeat it from a script.
Because the work around a model is larger than the model call. Separate providers mean separate sign-ups, secrets, request formats and error handling, and every comparison between models costs a new integration. With one key and one request shape you write that layer once and swap the model name when you want a different look. You still get the choice of models, without the maintenance.
The intended coverage is the text-to-image models of the catalog, 212 of the 502 models. Examples you can check today are google/nano-banana-pro, bytedance/seedream-5-pro, openai/gpt-image-2.5-flare and recraft-ai/recraft-v4.1-pro. Each page in the catalog shows what a model does, and the toolkit lets you run it, so you can pick before you build.
You create it in your account, the same account you use for the toolkit. Treat the key like a password: it identifies your requests and spends your credits, so keep it in a server-side secret store, never in a public repository, a front-end bundle or a screenshot. If you think a key has leaked, replace it and tell support if anything looks odd on your balance.
Each generation costs credits, and the amount depends on the model and on the settings you choose, such as the size of the output. This page quotes no number because plans and costs change, and a wrong figure would only mislead you. The pricing page holds the current plans, and running a prompt in the toolkit shows what a model costs you before you automate it.
Yes, and it is the recommended order. The toolkit runs the same catalog: pick a model, write the prompt, attach reference files if the model accepts them and generate. Do this until the output is something you would publish, then reuse the exact prompt and settings in your requests. Debugging wording in the toolkit is faster than debugging it inside a loop.
Several image models accept reference images next to the text, for example google/nano-banana-pro and bytedance/seedream-5-pro, and that is the usual way to keep a product or style steady across a batch. Which inputs a model takes depends on the model, so check how it behaves in the toolkit first. Only upload images you have the right to use, and keep real people out unless you are the person pictured.
It depends on the model, the settings and how busy things are, so there is no single honest number. Some generations come back quickly and larger or higher-quality ones take longer. Build for waiting: start the request, handle the result when it arrives, and never block a page load on a generation. Measure your own prompts in the toolkit to get a feel for it.
You can generate avatars of fictional characters and stylized portraits, and photos of yourself if you supply your own reference images. Do not generate real identifiable people without their agreement, and do not present a generated face as a real customer, employee or reviewer. Check the current rules of any platform where the avatar will appear, since they differ and change.
The intended coverage is the whole catalog: image, video, voice, music, upscale, background removal, 3D, lipsync and chat models, with the same key and the same credit system. This page focuses on images, because that is where most first integrations start. To see what else runs, open the collection and the toolkit, which already hold all of those model types.
Pick one prompt you would actually use, run it through a few models in the toolkit, and bring the winner to your code. Questions go to support.
Choose your language
