Part API versus Solid API

When developing with ClassCAD, you have two powerful APIs at your disposal:

• The Part API – ideal for building parametric, feature-based models.
• The Solid API – ideal for direct solid modelling or defining custom feature logic.

For new users, understanding how these two APIs differ – especially in how they handle solids and features – is crucial for building stable and flexible models. We see two philosophies in CAD programming: code-as-geometry and feature-by-feature APIs, as described in our blog article. By providing the Solid API in addition to the Part API, we bridge the gap between these philosophies.

You will always need a part created with api.v1.part.create to add features with the Part API or add custom Solid API code. To embed Solid API code in a part you need a special feature called EntityInjection.

---

Part API – Feature-Based Modeling

The Part API follows a history-based modelling approach, similar to how parametric CAD systems work.

Key Concepts

• You work with features, not solids.
• Every operation (like cylinder, extrusion, boolean) adds a feature to the model's history tree.
• The engine automatically tracks which solids are created by which features.
• Solids are internal results, not directly exposed. But they can be referenced also using solid indices if needed.

✳️ Example

const { result: flangeSolid1 } = await api.part.boolean({
  id: flange,
  type: 'UNION',
  target: baseCyl,
  tools: [upperCyl],
})

• This doesn’t just return a new solid — it creates a feature that will exist in the model history.
• You can’t directly manipulate the solid — instead, you operate at the feature level.

📝 Note: The code snippet above is written in TypeScript using our TypeScript API.

---

Solid API – Direct Solid Manipulation

The Solid API is embedded as a single feature in a part and works as the Code-as-geometry without a history.

Key Concepts

• You work directly with solids.
• Operations like union, translate, or extrusion return immediate solid geometry.
• There are api calls that can keep or discard solids using the keepTools flag.
• Useful for building custom operations or reusable feature logic
• Variables holding solids can easily be reused in subsequent operations, as long as they are not "consumed".
• Within the Solid API we do not support automatic referencing of BRep elements.

Example

const { result: part } = await api.part.create()
const { result: ei } = await api.part.entityInjection({ id: part })

 // body
const { result: basic } = await api.solid.box({ id: ei, width, height, length })
const { result: subBox } = await api.solid.box({
    id: ei,
    width: width - 2 * thickness,
    height: height - thickness,
    length: length - 2 * thickness,
 })
 await api.solid.translation({ id: ei, target:  subBox, translation: [0, 0, -thickness] })
 await api.solid.subtraction({ id: ei, target:  basic , tools: [ subBox ],  keepTools: true  })

• Here, you can reuse subBox because of keepTools: true.

📝 Note: The code snippet above is written in TypeScript using our TypeScript API.

---

🔄 Understanding Solids and Feature Dependencies

Why Part API Can Be Tricky

Using the Part API requires understanding how feature dependencies and solid lifecycles work:

• When you create a feature, it produces solids — but other operations can later consume that solid.
• To build reliable sequences, the system tracks which solids are still available at each step.
• Internally the system copies the solid so that the feature/solid can be used in a later feature. It seems to be an overhead creating all these copies, but it is absolutely necessary to efficiently implement the rollback bar or an open feature in our interactive environment Buerligons.
• Moving backward through the history of a part is basically managing consumed flags and visibility. Suppose the system would not copy these solids, then moving the rollback bar backward would result always in a highly inefficient and unnecessary recalculation of all features from the beginning up to the current feature!

⏪ Coding in Part API: Do not use operationMoveBefore and Rollback Bar

In history-based CAD systems, the model is evaluated top-down, feature-by-feature — like reading a script line-by-line. When inserting a new feature somewhere in a part in Buerligons, you move the rollback bar to the position in the feature list where you want to add the feature. This is where api.v1.part.operationMoveBefore comes into play; it is called from the React component for our feature tree.

There is NO need to use operationMoveBefore when coding, because you can simply add the new code at the adequate line in your code! BUT make sure, when you add a feature somewhere in the middle of the history and you consume features/solids, then these are no longer available later and you need to replace them with the new feature in the targets/tools parameter. Please note that internally we handle this automatically within our Buerligons system and replace correct targets. The system throws a runtime exception when executing code that accesses a consumed solid.

Coding in an entityInjection container API: Do not use feature-based modelling, clear or similar things

Custom scripts that run as an EntityInjection feature within a part execute automatically whenever the feature needs to be recalculated. This happens after changing global part expressions or when features earlier in the history are modified, which makes all later features dirty.

📝 Note: In the current version, we do not support the recalculation of EntityInjection features. This will be available in a later version. At the moment, the coded objects in EntityInjection behave like an imported STEP model.

When using a solid created with the Part API inside the Solid API, you need to call fromFeature from the Solid API before you can operate on the solid. This creates internal copies so that the original feature remains available when moving the rollback bar backward to the feature. A typical example is a custom perforated sheet part. Your base part is built in Part API and then you use Solid API to create a custom pattern of solids to be subtracted. Think about positioning the objects on a sine curve before subtracting.

Summary Table

For our users it is important to understand where we position ourselves in the CAD and code-CAD world. We think that interactive modeling and coding are interchangeable. That is why we provide both Buerligons for interactive modeling and the APIs to "DO IT IN CODE".

With these full-fledged parametric objects we build parts like other high-end modelers; however, we do not support as many modeling features. Full-fledged parametric objects are necessary for our long-term vision to be able to convert many parametric models between high-end CAD systems without losing the parametrics. We are aware that such conversions won't work 100% of the time.

On the other hand, with the Solid API we provide the ability to write code in a similar way to our code-based CAD competitors, avoiding the overhead of editing/managing features individually. Instead, users change parameters in code and recalculate everything from scratch. There are, of course, performance gains in the Solid API when you avoid the Part API overhead of managing a declarative operation sequence with feature objects.

Concept	Part API	Solid API
Modeling approach	Feature-based history	Direct/Solid modelling
Main object	Features	Solids
Output of operations	Feature	Solid
Access to solids	Feature and indices	Direct
Referencing	Yes, handled automatically	No
Interactive Selection	Yes	partly

---

💬 For New Users

• ✅ Start with the Part API if you're building a structured, parametric part.
• ✅ Use Solid API if you just want to create a custom part from code without history.
• ⚠️ Be mindful of feature/solid dependencies: solids created by "earlier" may be consumed.
• 🧠 Use operationMoveBefore and rollback bar only when you build a custom GUI for your CAD, and make sure you understand the model state at that point in the history. You might better contact us in this case.