API Usage
At first glance, our API documentation may appear detailed. This structure is intentional and helps address a wide range of use cases. The following hints will guide you through it.
Our CAD APIs support both part creation and assembly construction. We leveraged these APIs to develop Buerligons (buerligons.io), a parametric CAD system for end users. This showcases how you can use the APIs to build your own custom CAD applications. Starting from version v1, all APIs are versioned and follow clear, standardized design principles:
- JSON Parameters – All APIs accept a single JSON key-value parameter, making them more resilient to breaking changes.
- Result & Error Handling – Every API call returns a JSON object containing both a result and an error section. For typescript developer this is slightly adapted (see documentation on buerli.io).
The JSDoc documentation provides all the necessary details for using the APIs. We use this documentation to automatically generate a TypeScript API, with Python support coming soon.
Part API
This API enables you to create parts using a sequence of operations or features, similar to how parts are built interactively in Buerligons. Solid geometry is generated when the sequence is executed. The models created through code can also be opened and further modified within Buerligons.
Assembly API
The Assembly API enables constraint-based assembly construction. Models consist of parts and assemblies, which are stored in containers. These containers act as templates, allowing instances to be positioned in 3d space when creating new assemblies. Positioning is handled using 3D constraints, such as fastened, revolute, and slider constraints, which are defined on mates. Our 3D constraint solver ensures correct positioning of all components.
Solid API
For applications where only the final geometry matters, the Part API may not be the best approach. That’s why we offer a destructive Solid API, allowing you to programmatically generate solid geometry using extrusions, revolutions, and Boolean operations—without unnecessary steps. Here, you first create a part and then generate geometry within a solid container object. With Solid API we bridge the gap between declarative, scriptable geometry and feature based programming as described in our Blog article.
Sketcher API
This API enables the creation of parametric sketches with 2D constraints. Programming sketches can be complex because you’re not just defining geometry (lines and arcs) but also constraints. Once a constraint is added, the embedded solver applies it, potentially modifying the geometry accordingly. Sketches can be created on workplanes, including those defined on planar faces of BRep geometry. The interactive sketcher embedded in Buerligons follows the same principles.
Curve API
Beyond simple geometric elements like lines and arcs, the Curve API supports Bezier curves and polynomial-based interpolation. Additionally, it offers compatibility with AutoCAD’s polyline approach, using points and bulges. Curves can be grouped into shapes, which can then be used for extrusions or other operations.
Common API
Beside often used functionality like load, save and clear the common API offers batch processing API call and also the API for handling user data.
Drawing API
The Drawing API allows the creation of 2D drawings from 3D models. It internally applies hidden-line removal and projects 3D curves onto a plane. Users can define different views (e.g., TOP, ISO) and position them accordingly. For exporting, we use the Open Design Library to generate DXF and SVG formats.
Key Differentiators Compared to Other CAD API Providers
Self-Hosted Engine: You have full control over hosting the engine, making it accessible to your end users via web technologies. We do not provide a SaaS solution! Scaling in the cloud is central when you want to adapt the required computing resources to the number of users you want to serve.
WASM-Based Engine: Our WebAssembly (WASM) engine is a compact ~40MB package containing your entire CAD system. Your end users can run the application directly in their browser with just a single download—eliminating hosting costs on your side while supporting unlimited users. No install, just a single click. Our WASM engine is the simplest answer for scaling in the cloud.
Customizable with Buerli Client Framework: Easily tailor your CAD applications GUI with the Buerli Client framework, ensuring flexibility and adaptability to your needs.
Regardless of your company’s size, we provide an affordable flat-rate pricing model for businesses large and small. Since you host everything yourself, we offer a flat-rate pricing model; no per-API-call charges
Object or Objects
You often find in the documentation that param can be either an object or an array of objects containing all the parameters (for example, when creating lines, constraints, etc.).
The main reason is performance: when you use a network driven operation mode, you can avoid multiple request going through the network connection.
The target Param
Most features in part modeling manage a single solid; only a few, like the pattern feature, deal with multiple solids. If you need to access the i-th solid of a pattern, you must supply the target object with indices. Otherwise, provide the id for target, e.g. featureId.
In the example below, the second and fourth solids from the pattern feature together with the solid from feature shaft should be mirrored.
api.v1.part.mirror({ id: partId, targets: [ head1, shaft ], references: [15] });
api.v1.part.mirror({ id: partId, targets: [{ id: patternId, indices: [2,4] }, shaft ], references: [20] });
Points in Sketch API
When creating sketch geometry (for example, using line, arcByCenter, etc.), you must provide startPos and endPos as points in the format [x, y, z].
Since sketch geometry is always created on a workplane with its origin at (0, 0, 0) and oriented along the x-axis, the geometry must lie entirely on that plane. Therefore, only points with z = 0 are accepted.
This condition is enforced; supplying points with z ≠ 0 will result in an error. While this requirement can be somewhat inconvenient, it is acceptable given the significant additional effort that would be needed to support other 2D point types.