TABLE OF CONTENTS
Key takeaways
- Circuitly built a working Duro integration in roughly 18 hours, including component publishing, library mapping, design-file attachments, and change order creation.
- The important result was not speed alone. The integration let an AI-driven design workflow move quickly while Duro preserved review, approval, revision control, and traceability.
- Duro’s API-first architecture gives customers and partners access to the same core product model used by the Duro application, rather than a narrow integration layer added later.
- The best place to start is a bounded, high-friction workflow with a clear system of record and a human approval point.
Hardware development never involves just a single engineering application. Product data moves among ECAD and MCAD tools, sourcing platforms, ERP systems, manufacturing systems, and a growing number of AI agents. And if those systems can’t exchange data reliably and seamlessly, every handoff becomes another spreadsheet export that someone has to maintain.
Instead of this arduous process, we explored a better way to address this issue in our recent webinar with Circuitly. Circuitly founder and CEO Jeremy Gordon joined Duro founder and CEO Michael Corr and Head of Duro’s engineering team Dustin Diaz to demonstrate an agentic electronics workflow connected directly to Duro.
The headline was hard to miss: Circuitly built the integration in roughly 18 hours on Duro’s API.
Circuitly proved that when a PLM is designed as a programmable platform, companies can connect their own tools, encode their own processes, and automate the work that is unique to how they build hardware; all in record time.
What Circuitly demonstrated with Duro’s API
Circuitly is a browser-based harness for AI in electronics design. Its agents can work with native Altium, Cadence, and KiCad files, analyze designs, investigate sourcing risks, propose changes, and return the work as a reviewable result. Duro provides the governed product record around that work: components, assemblies, product structures, revisions, documents, and change orders.
In the webinar demonstration, Circuitly used the Duro API to inspect how a company had configured its Duro library, including its categories and attributes. It then mapped and published approximately 30 components, a bill of materials, and rendered design files into Duro. Rather than overwriting the official product record, Circuitly created change orders so the appropriate stakeholders could review what the agents had produced.
The workflow continued in both directions. Circuitly ran a supply chain risk review, identified a component with limited availability, researched an alternative, updated the schematic, and published the proposed revision to Duro through another change order. Circuitly could also read approved library data back from Duro, giving its agents access to parts the organization had already governed and approved.
That closed loop is the real value:
- An engineering system creates or modifies product data.
- Duro receives the proposed data and applies the company’s review and approval process.
- The approved product record becomes available to the rest of the toolchain.
- Engineering tools can use that governed data in the next design cycle.
Automation accelerates the work, but it does not erase ownership or control.
Why an API-first PLM improves integrations
Traditional PLM integrations are often treated as peripheral projects. A vendor exposes a small set of endpoints, a consultant connects two systems, and the resulting point-to-point integration works until one side changes. The customer is left with something expensive to modify, difficult to extend, and it typically takes weeks if not months.
An API-first PLM platform starts with a different assumption: the product itself is built on the API. Duro’s application uses the same core API surface available to customers and partners. As Dustin explained in the webinar, if the Duro team encounters friction while building its own product, it has to improve the same interface external developers use.
This matters for four reasons:
The API reflects the real product model
A developer can request the connected data a workflow needs without stitching together a long chain of narrow calls or retrieving large amounts of irrelevant information. That is especially useful for BOMs, where understanding the relationships among objects matters as much as reading the objects themselves.
Read and write access enable real workflows
A read-only API is useful for reporting, but it cannot close the loop. A useful PLM integration should not merely copy data out of the system. It should be able to return proposed work to the system of record through the same governed processes a person would use.
Product and API concepts stay aligned
Integrations become unnecessarily difficult when the object a user sees in the interface does not map cleanly to the object a developer sees in the API. Duro designed the product and API around the same concepts, which reduces translation work for both developers and AI coding agents.
Documentation is part of the product
AI can accelerate implementation, but it still needs context. A schema can describe what a field accepts but can’t always explain why a method exists, when to use it, or how it fits into a larger hardware workflow.
Duro’s developer documentation is structured for both people and AI tools, and is also maintained as the product evolves. That gave Circuitly a dependable source of evidence while it built the integration instead of forcing the team to infer how the platform was intended to work.
API access should not mean bypassing PLM controls
There is an understandable concern that more automation creates less control. In hardware, an unreviewed component substitution or an incorrect BOM revision can become a late delivery, a board respin, or a compliance issue.
To alleviate this worry, Duro’s API makes the control points explicit.
In the Circuitly workflow, agents could do the time-consuming work of inspecting files, mapping attributes, finding sourcing data, and preparing a change. Duro remained the authoritative record where the change was reviewed and approved. This separation lets each system do what it does best: the design environment helps engineers iterate, while the PLM preserves identity, lifecycle state, and decision history.
That is the practical meaning of a digital thread. Product data does not merely appear in several systems; it moves between them with its context intact. For a broader introduction to that role, see our guide to product lifecycle management.
How to build your own Duro integration using the API
Circuitly is a fantastic example of the custom workflows and tools that engineering teams can build on Duro’s API, in a matter of hours. Here’s how:
1. Choose one “expensive” handoff
Look for a repeated task in which structured product data is copied, retyped, or reconciled by hand. Good candidates include publishing an approved BOM to ERP, creating components from an ECAD library, checking released parts against sourcing data, attaching generated documents to a product record, or notifying another system when a change order reaches a specific state.
Define the result in operational terms. “Integrate PLM and ERP” is too broad. “Create or update ERP item records after a BOM is approved in Duro” is testable.
2. Decide which system owns each decision
An integration needs clear sources of truth for every important field and state. Duro may own customer part numbers, revision status, approved manufacturers, and released BOM structure. Another system may own inventory, purchase orders, or supplier lead times.
Write those boundaries down before building. Without them, a two-way sync can quickly become two systems overwriting one another.
3. Start with reads, then add controlled writes
Use the API to inspect representative data and confirm that your mapping works across real categories, attributes, and product structures. Once reads are reliable, add a staged write path. In many cases, the right first write is not “release this change” but “create a draft change order for review.” For example, this gives AI agents room to help while keeping a person at the highest-consequence decision point.
4. Prototype against a representative library
Duro customers can follow the API overview to create a library-specific API key, configure the required headers, and test a query in Duro’s GraphQL tool. Use a non-production or representative library when appropriate, and test both expected cases and messy ones: incomplete metadata, revised components, duplicate manufacturer part numbers, and failed approvals.
The goal of the prototype is not merely to prove that an API call succeeds, but also to prove that the workflow behaves correctly when product data is imperfect.
The larger opportunity is a programmable hardware stack
Circuitly’s 18-hour build is a useful benchmark, but it should not become another promise that integration work is effortless. The team brought deep software and electronics experience, an existing agentic platform, and a well-defined use case.
What changed is the starting point. Companies no longer have to accept a closed PLM, wait for a vendor to prioritize their connector, or fund a long custom project before testing an idea. A modern API gives them a credible path to build the workflow themselves, validate it quickly, and improve it as their process changes.
That matters because no PLM vendor can anticipate every tool or process a hardware company will use. The purpose of an open platform is not to supply every possible integration. It is to provide a stable, governed product-data foundation on which customers and partners can create them.
Watch the Duro and Circuitly webinar to see the workflow in action. Ready to give Duro a shot? Click here to request a demo and discuss with our team the systems you want to connect.