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.

Get Your API Key →Read API Docs →

# 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"}'

A reference image and the 3D crate model the PicoBerry API generates from it

POST /v1TripoMeshyHunyuan3DImage ModelsWebhooksMCP

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.

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, scope it to your integration, and keep it server-side. Use separate keys for environments, tools, or teams when you need usage visibility.

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.

Usage & Credit Tracking

Track credit usage from the dashboard so teams can separate development, internal tools, customer-facing features, and experiments before scaling a generation workflow.

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.

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 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?

Start by creating a PicoBerry account, requesting API access, and integrating the first server-side call. Keep API keys out of client-side code and use separate keys for environments or products when needed.