Text-to-CAD API: what's available and how to use it

I spent a Friday afternoon trying to build a small internal tool that generates bracket variations from a spreadsheet. The idea was simple: read a row, construct a prompt, hit an API, get a STEP file back. The kind of thing you'd wire up in an hour if the API existed and the documentation didn't lie. I had a Python script open, a list of twelve bracket specs in a CSV, and the quiet optimism of someone who hasn't yet tried to find a working text-to-CAD API.

Two hours later, I had one API that actually worked, three that turned out to be mesh generators wearing CAD clothing, and a growing appreciation for just how thin the field is. If you're a developer trying to generate real CAD geometry programmatically from text prompts, the options are fewer than you'd expect and more specific than you'd hope.

The actual landscape#

As of early 2026, there is essentially one production-ready text-to-CAD API: Zoo.dev. That's it. There are other tools that generate 3D content from text, plenty of them, but they produce meshes. OBJ files, FBX, triangle soups that look like CAD parts in a viewport and fall apart the moment you try to select a face or measure an edge. If you need B-Rep geometry, the kind of solid you can open in Fusion 360 and actually edit, Zoo is where you end up.

I don't love having a single real option. But the reason there's only one production text-to-CAD API isn't gatekeeping. Generating B-Rep from text is genuinely hard, and most companies working on AI 3D are targeting gaming and entertainment, where meshes are the native format. Engineering CAD is the harder problem with the smaller market.

There are research projects and open-source experiments. The Text2CAD paper has public code. You can wire up an LLM to generate OpenSCAD scripts. But none of these have a stable, documented API you'd integrate into a production pipeline. They're building blocks, not services.

Zoo.dev API: what you're actually working with#

The Zoo API is a REST API. The core endpoint is straightforward:

POST /ai/text-to-cad/{output_format}

You send a JSON body with a prompt field, specify your output format in the URL path, and get back a response with a job ID. The generation is asynchronous. You submit the request, get a UUID, then poll until the status flips from in_progress to completed (or failed, which happens more often than the marketing page implies). Once it's done, you fetch the output, which comes back as base64-encoded file data.

Supported output formats: STEP, glTF, glB, OBJ, PLY, STL, and FBX. For engineering work, you want STEP. For visualization or quick previews, glTF or STL. The API returns both STEP and glTF by default, which is a sensible choice since you usually want one for CAD and one for web rendering.

Authentication is token-based. You generate an API token from your Zoo account, set it as the ZOO_API_TOKEN environment variable or pass it in the Authorization header, and you're in. No OAuth dance. Just a bearer token.

The status lifecycle goes: queued → in_progress → completed or failed. Typical generation takes 15 to 90 seconds. A simple bracket might come back in 20 seconds. Something with more features takes longer.

The SDK situation#

Zoo publishes official client libraries for Python, Go, Rust, and TypeScript. The Python SDK (kittycad) is the most mature and the one I've used the most. It wraps the REST endpoints in typed function calls and handles the polling loop for you.

For a hands-on walkthrough of the Python SDK, the text-to-CAD API Python post covers installation, authentication, and the generate-poll-save workflow.

The TypeScript and Go clients exist and work, but the Python one has the most examples. There's also a CLI (zoo) that wraps the API for command-line use. You can run zoo ml text-to-cad with a prompt and an output format and get a file back without writing any code.

Pricing and limits#

Zoo gives you $10 of free API usage per month. That translates to roughly 20 minutes of compute time, which doesn't sound like much until you realize each generation takes 15 to 90 seconds. You can generate somewhere around 15 to 50 parts per month on the free tier, depending on complexity. For testing and light use, that's enough. For a batch pipeline that processes a hundred parts a week, you'll need to pay.

Paid usage is $0.0083 per second, which works out to $0.50 per minute. Failed calls aren't charged, which is fair and also necessary given that the model doesn't succeed every time. A Pro subscription ($25/month for individuals, last I checked) gives you unlimited text-to-CAD through the web UI and the API.

No published rate limits that I've found, but I've hit implicit throttling when I was hammering the endpoint with a batch of 30 requests in rapid succession. Spacing requests a few seconds apart solved it. If you're building something that needs high throughput, you'd want to talk to Zoo about that.

What the API can and can't do#

It can generate B-Rep geometry from natural language descriptions of mechanical parts. Brackets, plates, enclosures, housings, standoffs, flanges, simple gears, basic structural elements. The geometry comes out as real solids with selectable faces and edges that import cleanly into Fusion 360, SolidWorks, or any STEP-compatible tool.

It can't generate assemblies. One prompt, one part. If you need a mechanism with multiple interacting components, you're generating each one separately and assembling them yourself.

It can't do organic or freeform surfaces. Ask for something with complex curvature, a car body panel, a consumer electronics shell with flowing surfaces, and the output will either be a crude approximation or a failure.

It doesn't handle tolerances, GD&T, or material specifications. The output is nominal geometry with no manufacturing metadata. You get shapes, not engineering intent.

It doesn't guarantee dimensional accuracy. I've written about this in the accuracy post, but the short version is: dimensions are usually close but not exact. A 50mm feature might come out as 49.5mm or 50.3mm. For prototyping, fine. For production, you need to verify and correct every dimension. The API doesn't solve this; it's a property of the underlying model.

Building a batch workflow#

The most useful thing I've done with the API is the bracket generator I mentioned at the start. Here's the shape of it: a CSV with columns for type, length, width, thickness, hole count, and hole diameter. A Python script reads each row, builds a prompt string, calls the API, polls for completion, and saves the resulting STEP file with a name derived from the row data. Forty lines of Python plus the kittycad SDK doing the heavy lifting.

The tricky parts are error handling and prompt construction. The API fails on maybe 10 to 15 percent of prompts in my experience, sometimes with a useful error message ("The prompt must clearly describe a CAD model"), sometimes with a generic failure. Your batch script needs to handle retries gracefully and log failures for manual review. I retry once with a slightly rephrased prompt. If it fails again, I log it and move on. Fighting with the model over one stubborn prompt isn't worth the compute time.

Prompt construction is where domain knowledge matters. "L-bracket with holes" gives you something. "L-bracket, 3mm aluminum, 40mm equal legs, two M4 clearance holes per leg on 25mm spacing, 10mm from edges, 2mm fillet at bend" gives you something much closer to usable. The API doesn't know what you need unless you tell it. Vague in, vague out. The text-to-CAD guide has more on prompt strategy.

For a complete working tutorial that starts with a raw curl command and builds up to a Python batch script, see the Zoo text-to-CAD API tutorial.

Alternatives and workarounds#

If Zoo's API doesn't fit your needs, the alternatives require more assembly.

You can set up a language model (GPT-4, Claude, local models) to generate OpenSCAD code from text prompts, then run OpenSCAD to render the geometry. This gives you a "text-to-CAD API" that you control, but the output is limited by OpenSCAD's geometry capabilities (CSG only, STL export rather than STEP).

You can do the same thing with FreeCAD's Python API, which gives you proper B-Rep with STEP support, but the failure rate is higher because FreeCAD's API is large and LLMs get the details wrong more often.

MCP servers that connect language models to CAD tools are another emerging option. The geometry quality is excellent when it works, but these are research-grade tools, not production APIs.

For more on the Python-specific options, see the text-to-CAD API Python walkthrough, which covers both the Zoo SDK and the DIY approaches.

The developer experience, honestly#

The Zoo API works. The documentation is adequate. The SDK saves time. The pricing is reasonable. Generation quality varies but is mostly usable for simple to moderate parts. The async model is a minor annoyance that you wrap once and forget about.

What's missing is everything around the core API. There's no webhook support for completion notifications, so you're stuck polling. There's no batch endpoint, so generating 50 parts means 50 individual POST requests. There's no way to specify constraints or relationships between features in the prompt format, which means the API is always interpreting rather than following instructions. And there's no feedback mechanism more nuanced than thumbs-up/thumbs-down to help the model learn from your corrections.

I also wish there were more providers. Competition would improve everything: pricing, quality, feature sets, documentation. Having one vendor for the entire category makes me nervous in the same way that depending on a single supplier for a critical component makes me nervous.

For now, the Zoo API is the tool we have. It's real, it works for specific use cases, and the KittyCAD Python SDK makes integration straightforward. Whether it's the tool you need depends on what you're building and how much imperfection you can tolerate in the output. The API is an accelerator, not a replacement, and the developers who treat it that way seem to be the ones getting actual value from it.