Tripo creates 3D model assets from a description or visual reference. Its workflows separate the generation of an object from later steps such as texturing, rigging and conversion. Start by identifying the intended asset and the operation that produces it: a static mesh for a scene, a textured object for rendering or a model that will receive further preparation in a 3D editor.
For a text-to-model brief, describe the object’s shape and its important parts. A small lantern can be specified through its body, handle, openings and proportions; a creature through its silhouette, limbs and pose. State the material or visual treatment when it matters to the result. Keep the description focused on the object itself so the generated geometry can be assessed against a clear design.
For a reference-based maker workflow, prepare images that show the subject’s outline and distinguishing features. Several views should describe the same object with consistent proportions and accessories. Review parts hidden in the reference after generation, because a convincing front view does not establish that the back, underside or connections between components match the intended design.
Keep the selected model version with the request. Tripo’s generation interface identifies the operation separately from the model-version setting, and the documented text-to-model example chooses an explicit version. Preserve the exact version and controls when comparing assets so a change to the object description is not confused with a change to the generation configuration.
Geometry and surface appearance are separate production decisions. The maker’s base workflow distinguishes an untextured model from an output with textures and physically based rendering materials. Choose the form of the asset needed for the next step, then inspect both the mesh and any accompanying material files. A preview image is useful for orientation, while the actual model is the artifact needed for scene assembly and further editing.
Examine the completed object from several angles. Look at the silhouette, the separation of parts, thin features, openings and surfaces where components meet. For a stylized prop, compare the proportions with the design brief. For a product-like object, check which details are represented by geometry and which appear only in the surface treatment. Identify the feature that needs revision before changing the prompt or reference.
Generation runs as an asynchronous task. Retain the original task identity through status checking and keep the completed model, preview and any other returned files together. The documented result includes model-related output fields and rendered imagery. Save the files themselves for the next production step rather than relying on a temporary result link or treating the preview as the complete 3D deliverable.
Import the model into the intended editor or viewing environment and inspect its orientation, scale, materials and geometry there. A scene prop, a close-up render and an animation-ready character have different finishing needs. Keep a working copy for edits and retain the generated source asset with its brief and references. When another operation is needed, such as texture work or rigging, choose that operation deliberately and review the resulting asset as a separate stage.
", "aboutText": "Tripo creates 3D model assets from a description or visual reference. Its workflows separate the generation of an object from later steps such as texturing, rigging and conversion. Start by identifying the intended asset and the operation that produces it: a static mesh for a scene, a textured object for rendering or a model that will receive further preparation in a 3D editor.\n\nFor a text-to-model brief, describe the object’s shape and its important parts. A small lantern can be specified through its body, handle, openings and proportions; a creature through its silhouette, limbs and pose. State the material or visual treatment when it matters to the result. Keep the description focused on the object itself so the generated geometry can be assessed against a clear design.\n\nFor a reference-based maker workflow, prepare images that show the subject’s outline and distinguishing features. Several views should describe the same object with consistent proportions and accessories. Review parts hidden in the reference after generation, because a convincing front view does not establish that the back, underside or connections between components match the intended design.\n\nKeep the selected model version with the request. Tripo’s generation interface identifies the operation separately from the model-version setting, and the documented text-to-model example chooses an explicit version. Preserve the exact version and controls when comparing assets so a change to the object description is not confused with a change to the generation configuration.\n\nGeometry and surface appearance are separate production decisions. The maker’s base workflow distinguishes an untextured model from an output with textures and physically based rendering materials. Choose the form of the asset needed for the next step, then inspect both the mesh and any accompanying material files. A preview image is useful for orientation, while the actual model is the artifact needed for scene assembly and further editing.\n\nExamine the completed object from several angles. Look at the silhouette, the separation of parts, thin features, openings and surfaces where components meet. For a stylized prop, compare the proportions with the design brief. For a product-like object, check which details are represented by geometry and which appear only in the surface treatment. Identify the feature that needs revision before changing the prompt or reference.\n\nGeneration runs as an asynchronous task. Retain the original task identity through status checking and keep the completed model, preview and any other returned files together. The documented result includes model-related output fields and rendered imagery. Save the files themselves for the next production step rather than relying on a temporary result link or treating the preview as the complete 3D deliverable.\n\nImport the model into the intended editor or viewing environment and inspect its orientation, scale, materials and geometry there. A scene prop, a close-up render and an animation-ready character have different finishing needs. Keep a working copy for edits and retain the generated source asset with its brief and references. When another operation is needed, such as texture work or rigging, choose that operation deliberately and review the resulting asset as a separate stage.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "e610e5d17ebe8d9d21d1b035b6b38b5e48c68c6958819e550e5375f65550c964", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "tripo3dTripo creates a 3D model asset from a written object brief. Its broader maker workflows distinguish geometry, texturing and later model processing; inspect the completed mesh from several viewpoints and retain the actual files for the target scene or editor.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
Tripo creates 3D model assets from a description or visual reference. Its workflows separate the generation of an object from later steps such as texturing, rigging and conversion. Start by identifying the intended asset and the operation that produces it: a static mesh for a scene, a textured object for rendering or a model that will receive further preparation in a 3D editor.
For a text-to-model brief, describe the object’s shape and its important parts. A small lantern can be specified through its body, handle, openings and proportions; a creature through its silhouette, limbs and pose. State the material or visual treatment when it matters to the result. Keep the description focused on the object itself so the generated geometry can be assessed against a clear design.
For a reference-based maker workflow, prepare images that show the subject’s outline and distinguishing features. Several views should describe the same object with consistent proportions and accessories. Review parts hidden in the reference after generation, because a convincing front view does not establish that the back, underside or connections between components match the intended design.
Keep the selected model version with the request. Tripo’s generation interface identifies the operation separately from the model-version setting, and the documented text-to-model example chooses an explicit version. Preserve the exact version and controls when comparing assets so a change to the object description is not confused with a change to the generation configuration.
Geometry and surface appearance are separate production decisions. The maker’s base workflow distinguishes an untextured model from an output with textures and physically based rendering materials. Choose the form of the asset needed for the next step, then inspect both the mesh and any accompanying material files. A preview image is useful for orientation, while the actual model is the artifact needed for scene assembly and further editing.
Examine the completed object from several angles. Look at the silhouette, the separation of parts, thin features, openings and surfaces where components meet. For a stylized prop, compare the proportions with the design brief. For a product-like object, check which details are represented by geometry and which appear only in the surface treatment. Identify the feature that needs revision before changing the prompt or reference.
Generation runs as an asynchronous task. Retain the original task identity through status checking and keep the completed model, preview and any other returned files together. The documented result includes model-related output fields and rendered imagery. Save the files themselves for the next production step rather than relying on a temporary result link or treating the preview as the complete 3D deliverable.
Import the model into the intended editor or viewing environment and inspect its orientation, scale, materials and geometry there. A scene prop, a close-up render and an animation-ready character have different finishing needs. Keep a working copy for edits and retain the generated source asset with its brief and references. When another operation is needed, such as texture work or rigging, choose that operation deliberately and review the resulting asset as a separate stage.
POST /v1/3d/generationstextmodel_3d, image| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits tripo3d Conditions: Use the Ailoot model selector. | Default— |
Fieldtype | Typestring | RequirementRequired | Values & limits text_to_model, image_to_model, multiview_to_model, texture_model, animate_prerigcheck, animate_rig, animate_retarget, stylize_model, convert_model Conditions: The complete example uses text_to_model; other task types require their documented task-specific inputs. | Default— |
Fieldmodel_version | Typestring | RequirementRequired | Values & limits v2.0-20240919, v1.4-20240625, v2.5-20250123, v3.0-20250812, Turbo-v1.0-20250506 Conditions: Select an explicitly documented version; this example uses v3.0-20250812. | Default— |
Fieldprompt | Typestring | RequirementRequired | Values & limits Conditions: Describe the object to create. | Default— |
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, type, model_version, prompt |
Parameteroptional | Contract |
Parametermaterial_types | Contracttext |
Parameterconditions | ContractUse the Ailoot model selector., The complete example uses text_to_model; other task types require their documented task-specific inputs., Select an explicitly documented version; this example uses v3.0-20250812., Describe the object to create. |
Lifecycle: submit_once_poll_original
GET /v1/3d/generations/{request_id}
GET /v1/media/assets
GET /v1/media/assets/{asset_id}
The displayed rates estimate the cost before generation. The final charge is calculated from the cost recorded for the original generation. Measured output duration and forecast quantities are not the final billable quantity.
Tariff references do not add request options. Supported parameters are listed for the selected method.
Match each charge to the conditions shown. Use one rate for each set of alternative configurations.
| Configuration | Rate schedule | Forecast quantity | Charge |
|---|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Forecast quantity— | Charge Input · Input tokens · Estimate for comparison only — / 1K tokens Output · Output tokens · Estimate for comparison only — / 1K tokens Input · Cache read · Estimate for comparison only — / 1K tokens Input · Cache write · Estimate for comparison only — / 1K tokens Input · Cache write, 1 hour · Estimate for comparison only — / 1K tokens |
| ConfigurationEstimated generation cost | Rate schedule— | Forecast quantityone generation estimate | Charge Output · Estimated generation cost · Estimate for comparison only $1.35 estimate before generation This estimate is not an additional charge or a fixed rate for the completed generation. |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\ncat > request.json <<'JSON'\n{\n "model": "tripo3d",\n "type": "text_to_model",\n "prompt": "a cute pig",\n "model_version": "v3.0-20250812"\n}\nJSON\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/3d/generations \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\n# Create once; retain id, polling_url, original task identifiers and every header.\nset -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_STATUS'\nimport json,os,subprocess\nfrom pathlib import Path\nfrom urllib.parse import urljoin,urlsplit\nr=json.loads(Path("result.json").read_text())\nu=urljoin("https://api.ailoot.ai",r["polling_url"])\np=urlsplit(u)\nif p.scheme!="https" or p.netloc!="api.ailoot.ai" or p.username or p.password:\n raise SystemExit("Unexpected returned polling URL; preserve the response")\nsubprocess.run(["curl","--fail-with-body","--silent","--show-error",u,"-H","Authorization: Bearer "+os.environ["AILOOT_API_KEY"],"-D","status-headers.txt","-o","status.json"],check=True)\n# Read this same original polling_url again while pending.\n# Preserve unknown/result_pending_check; do not repeat creation.\nPY_STATUS\nset -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\nexport AILOOT_API_KEY\npython3 - <<'PY_ASSETS'\nimport json,os,subprocess\nfrom pathlib import Path\nfrom urllib.parse import urljoin,urlsplit\nr=json.loads(Path("status.json").read_text())\nroles={}\ndef visit(v,path=""):\n if isinstance(v,dict):\n for k,x in v.items(): visit(x,path+"/"+k)\n elif isinstance(v,list):\n for i,x in enumerate(v): visit(x,path+"/"+str(i))\n elif isinstance(v,str):\n u=urljoin("https://api.ailoot.ai",v); p=urlsplit(u)\n if p.scheme=="https" and p.netloc=="api.ailoot.ai" and not p.username and not p.password and p.path.startswith("/v1/media/assets/") and p.path.endswith("/content"):\n roles.setdefault(u,[]).append(path)\nvisit(r)\nif not roles: raise SystemExit("No completed owned assets; retain the original status")\nmanifest=[]\nfor i,(u,paths) in enumerate(roles.items()):\n target=Path(f"asset-{i}.bin")\n subprocess.run(["curl","--fail-with-body","--silent","--show-error",u,"-H","Authorization: Bearer "+os.environ["AILOOT_API_KEY"],"-o",str(target)],check=True)\n raw=target.read_bytes()\n if not raw: raise SystemExit("Empty asset; retain original status and metadata")\n ext="glb" if raw[:4]==b"glTF" else "png" if raw[:8]==b"\\x89PNG\\r\\n\\x1a\\n" else "jpg" if raw[:3]==b"\\xff\\xd8\\xff" else "webp" if raw[:4]==b"RIFF" and raw[8:12]==b"WEBP" else "mp4" if raw[4:8]==b"ftyp" else "bin"\n name=f"asset-{i}.{ext}"\n if target.name!=name: target.rename(name)\n manifest.append({"file":name,"response_paths":paths,"bytes":len(raw)})\nPath("asset-manifest.json").write_text(json.dumps(manifest,indent=2))\nprint("Saved",len(manifest),"unique owned assets; every response role retained")\nPY_ASSETS\nDownload each returned image or save its Base64 contents
GET /v1/3d/generations/{request_id}GET /v1/media/assetsGET /v1/media/assets/{asset_id}Keep every complete returned response, file and content part.
Retain the complete response and headers, original identifiers, every actual output and all usage/accounting fields. Save each unique owned asset and retain every role pointing to it.
Keep the returned public task or operation id and all headers. Read only the original task; unknown or result_pending_check does not authorize another creation.
| Field | Type |
|---|---|
Fieldid | Typestring |
Fieldpolling_url | Typestring |
Fieldprovider_task_id | Typestring |
Fieldcode | Typeinteger |
Fielddata.task_id | Typestring |
Fielddata.status | Typestring |
Fielddata.progress | Typeinteger |
Fielddata.output.* | Typestring |
Fielddata.result.*.url | Typestring |
Fielddata.result.*.type | Typestring |
Fielddata.thumbnail | Typestring |
Ailoot Ultra tripo3d
Use the method paths shown above.