Developer API

AI 3D Generation API — Multiple Engines, One API

Add AI 3D generation to your product without building a model-switching, queueing, export, and asset-delivery stack yourself. PicoBerry gives your app one async API for text-to-3D, image-to-3D, refinement steps, and downloadable game-asset outputs.

# Generate a 3D model from an image
curl -X POST https://api.picoberry.ai/v1/models/from-image \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{"imageUrl":"https://.../ref.png","engine":"tripo"}'
POST /v1TripoMeshyHunyuan3DImage ModelsWebhooksMCP

How do you add AI 3D generation to your own app?

Create an API key in your PicoBerry dashboard and keep it server-side, then POST a prompt or image URL with your engine choice and output preferences to a /v1 endpoint. Your app gets a task identifier back — poll it, or register a webhook so your backend is notified when the job lands. When it finishes, download the finished model and hand it to your own product.

Ship 3D Generation Without Building the Pipeline

A model endpoint alone rarely gets you there. A real integration needs all of this:

  • Upload handling
  • Engine selection
  • Async job tracking
  • Result storage
  • Export formats
  • Usage control
  • Asset delivery

PicoBerry wraps that whole pipeline behind one API.

text or image → 3D
# prompt/image → 3D
POST /v1/models/from-image
{ "imageUrl": "ref.png", "engine": "tripo" }

Text & Image to 3D

Accept either a text prompt or a reference image, generate a 3D candidate, then continue with follow-up operations such as remesh, retexture, rigging, and export without moving the asset between vendors.

one contract, many engines
# same request, switch engines
{ ..., "engine": "tripo" }
{ ..., "engine": "meshy" }
{ ..., "engine": "hunyuan3d" }

Multiple Engines, One Contract

Route each request to the engine that fits the job. Try Tripo for one prompt, Meshy for another, and Hunyuan3D for another while keeping the same auth, job, asset, and export pattern in your code.

submit → poll or webhook
# submit → get a task id
{ "taskId": "job_a1b2", "status": "queued" }
# poll/webhook until succeeded

Async by Design

3D generation is not instant, so the API is designed around production queue behavior: submit work, store the task ID, poll or receive a webhook, then let your app continue when the result is ready.

Build the pipeline yourself, or make one API call

Either way, the finished 3D asset is the same. What changes is how much of the queueing, engine plumbing, storage, and delivery you own versus call.

What you handle
Roll your own
PicoBerry API
Engine access
Integrate and maintain each vendor SDK on its own
One contract routes to Tripo, Meshy, or Hunyuan3D
Long-running jobs
Build the queue, retries, and status store yourself
Submit a job, keep the task id, poll or get a webhook
Result files
Host and serve the generated models yourself
Fetch a finished GLB from the returned model URL
Agent access
Wire up your own tool interface for agents
Point AI agents at the PicoBerry MCP server
Auth API key (Bearer)Base URL api.picoberry.ai/v1Input Text or imageEngines Tripo · Meshy · Hunyuan3DOutput GLBJobs Async · poll or webhookSpec OpenAPIAgents MCP serverBilling Credit-based

From API Key to Downloaded Asset

A typical integration starts small: create an API key, submit a generation job, track status, then attach the finished asset to your own user flow, workspace, inventory, editor, or pipeline.

STEP 01

Get an API key

Create a key in your PicoBerry dashboard, name it after the integration that uses it, and keep it server-side. Use separate keys for environments or tools, so you can revoke one without touching the others.

STEP 02

Submit a job

Send a prompt, image URL, engine choice, and output preferences to a /v1 endpoint. Your app receives a task or asset identifier immediately instead of blocking the user interface.

STEP 03

Poll or get a webhook

Track the job by task ID, or register a webhook so your backend can update the user, refresh a workspace, or trigger the next step in an automated content pipeline.

STEP 04

Download the asset

Fetch the finished model and hand it to your own product: show it in a web viewer, attach it to a project, send it to a game-engine workflow, or store it for later editing.

Developer-First Features

This is for products and teams that need repeatable asset generation — not a one-off demo, but something that keeps running in places like these.

Internal toolsCreator workflowsGame-asset marketplacesAI agentsAutomated content pipelines

OpenAPI Spec & Typed Clients

Use the OpenAPI spec as the source of truth for requests and responses. Import it into Postman during exploration, then generate typed clients for your backend language when the integration moves into production.

Webhook Delivery

Use signed callbacks to move from polling to event-driven workflows. When a generation finishes, your service can update project state, notify a user, enqueue review, or trigger export handling.

MCP Server for AI Agents

Connect generation to AI coding tools and agent workflows through the PicoBerry MCP server. Agents can request asset candidates as part of a larger app, game, or tool-building flow.

Credit Usage & Key Controls

See your credit balance and usage history in the dashboard. Each API key is managed on its own — revoke one without affecting the others — and a per-key daily safety limit (20,000 credits) pauses a key once it hits that amount in a day, so a leaked key can’t keep running unchecked.

Add 3D generation with one API call

Create a server-side key, submit your first job, and let a webhook tell your backend when the model is ready to download.

Server-side API key · usage tracked in your dashboard

A Real Game-Asset Workflow in Motion

The embedded demo shows why the API matters beyond a single generation result: assets need to move from creation into an actual scene, work with the engine workflow, and be judged in play context.

Demo video: generated and edited 3D assets moving through a Unity scene, showing the handoff from asset creation to in-game validation.

FLOW 01

Generate candidates fast

Use the API to create props, items, characters, or environment pieces from a prompt or reference image, then keep the selected result as a trackable asset record.

FLOW 02

Fit assets into the game scene

The demo shows the practical next step: place generated 3D assets into a Unity workflow where scale, silhouette, lighting, masking, and scene composition decide whether the asset works.

FLOW 03

Close the loop with play-testing

The goal is not a standalone model preview. It is a faster generate → integrate → test loop so developers can evaluate assets inside the actual game experience.

What can one developer ship with this API in 12 hours?

The Legend of Deller is a playable isometric action RPG built by a single developer who wired the PicoBerry API into a coding agent. Every 3D asset in it — village buildings, dungeon architecture, props, NPCs, the boss guardian — was generated through the API. Idea to playable build took about twelve hours.

The developer walks through how it was made — describing the mood to the agent, generating the assets through the API, then tuning placement and motion by hand. English narration and subtitles.

~12 hours idea to a playable build158 GLB files 113 unique assets plus animation variants and LODs3 spaces village, dungeon, and boss sanctuary0 external DCC tools used for rigging or weights
STEP 01

Concept before assets

Three spaces were fixed first — village, dungeon, boss sanctuary — and a look was generated for each, so every asset afterwards had a target to match.

STEP 02

API wired into the coding agent

The PicoBerry API was connected to the agent. Where no reference image existed, the agent wrote the generation prompt from a description of the intended mood and object.

STEP 03

Placement stayed manual

The agent handled 3D coordinates well enough to assemble scenes, but position, rotation, and scale still needed a person — so the agent was asked to build a placement editor, and the village was tuned by eye.

STEP 04

Animation without a DCC round-trip

Base motion was generated through PicoBerry animation and checked on screen, then taken into three.js where bone positions and keyframes were adjusted directly, with no Blender rigging pass in between.

A custom in-browser placement editor showing transform controls for a scene object

The placement editor the agent built

Position, rotation, and scale for every object in the scene, with snapping and undo. This is the part the API does not do for you — and it was solved by having the agent build the tool instead of round-tripping through a DCC package.

The finished village running as a playable browser game with gameplay UI

Running in the browser

The finished village in play: NPC dialogue, skill bar, and minimap, with the generated assets carrying actual gameplay rather than sitting in a model viewer.

Cutting the hours I would have spent on rigging and weighting, and spending them on how the motion actually reads in-game, is what made this fast.

The developer who built it

He is equally clear that it is not finished: the animation still needs detail work, and the assets are a starting point rather than a final pass. What changed is not that the work disappeared — it is where the twelve hours went.

See It Working

The API should be judged by what it lets your product do: create a candidate, compare results, keep the asset record, and deliver a usable file into the next step of your workflow.

Generated 3D asset candidate 1 from the PicoBerry API
Generated 3D asset candidate 2 from the PicoBerry API
Generated 3D asset candidate 3 from the PicoBerry API
Generated 3D asset candidate 4 from the PicoBerry API
Generated 3D asset candidate 5 from the PicoBerry API
Generated 3D asset candidate 6 from the PicoBerry API

A range of generated 3D candidates your product can present for review, selection, refinement, or downstream export.

The PicoBerry API Quickstart docs page

The Quickstart path: authenticate, submit the first request, inspect the response, and connect generation to your own backend flow.

submit → asset · curl
{ "success": true, "data": {
  "id": "019f3a39-0db2-…",
  "taskStatus": 0,
  "type": "model_3d"
} }

# later
{ "modelUrls": { "glb": ".../model.glb" } }

Example async flow: submit a job, persist the returned identifier, poll or receive completion, then fetch the generated model URL.

Frequently Asked Questions

What is the PicoBerry API?

The PicoBerry API is an async REST API for AI 3D generation. It lets your backend submit generation jobs, track status, receive completion events, and fetch generated model files for product or pipeline use.

Can I use multiple generation engines through one API?

Yes. PicoBerry is designed to let teams route work across multiple generation engines through one product-side contract. Keep the same auth, job tracking, asset records, and export flow while selecting the engine that fits the request.

Is the API only for games?

No. The page focuses on game tools and 3D asset pipelines because that is PicoBerry’s core workflow. The same API pattern can support creator tools, marketplaces, internal automation, AI agents, education tools, and other 3D-enabled products.

Are generated assets immediately production-ready?

Treat generated assets as candidates. They are useful for prototyping, iteration, review, and downstream handoff. Depending on your project, you may still review topology, materials, scale, rigging, collisions, licensing, and engine-specific requirements.

Does PicoBerry support webhooks?

Yes. The API workflow is asynchronous: submit a generation job, keep the returned identifier, then poll or receive a webhook when the job is complete.

How do developers get started?

Create a PicoBerry account on a paid plan — or make any credit-pack purchase — then mint an API key yourself in the dashboard; there is no access request or waitlist. Free accounts see the dashboard but get 403 on /v1 until a payment is on file. Integrate the first call server-side, keep API keys out of client-side code, and use separate keys for environments or products when needed.

Build the 3D generation layer once. Use it everywhere your product needs assets.

Start with one API call, then connect generation to your app, tool, agent, or game-asset pipeline.

One async API · switch engines without changing your integration