Custom Data Source

Validation logic is only as reliable as the data it validates against. Custom data sources connect your authoritative external systems into Altium platform processes – so that checks run against current, live data, not a snapshot that goes stale.

Within Behavior Extensibility, custom data sources are not a separate infrastructure component – they are a pattern for how Python checks and scripts access external data. A check written in Python can call any accessible API, query any reachable database, and use the result as part of its validation logic. The external system remains the authoritative source. Altium queries it; it doesn't maintain a copy.

This is what makes the Customizability claim in the roadmap concrete: "A check can reach out to your internal parts database, your approved vendor list, your ERP system, and return a result." The custom data source is the call that makes that happen.

Why Live Data Access Matters

A check that validates component approval against a static list embedded in the check logic will be correct when written and wrong within weeks. Approved parts lists change. Restricted materials lists change. Lifecycle statuses change. A check that calls your live system gets the current answer every time it runs.

This is the difference between encoding a rule and encoding knowledge. A static list encodes the state of knowledge at a point in time. A live data source call encodes the rule that the current state of an authoritative system determines compliance. The second approach ages better.

Common External Data Sources

• Approved Vendor / Manufacturer Lists (AVL/AML) – your procurement or component engineering team maintains the authoritative list of approved manufacturers and vendors. A check that queries this list live ensures that a component flagged as approved in Altium was actually approved in the authoritative system as of the moment the check ran – not as of the last time someone updated a local file.

• Component qualification databases – organizations with mature component qualification processes maintain internal databases of qualification status, test data, application restrictions, and approved use cases. Connecting this data into Altium checks means qualification status is visible and enforced at the design stage, not discovered at release review.

• ERP and inventory systems – checks that validate lead times, inventory levels, or procurement status against live ERP data let engineers make sourcing-aware decisions during design, rather than discovering supply problems after the design is complete.

• Compliance and restricted materials databases – ITAR, EAR, RoHS, REACH, and internal IP control lists are maintained by compliance teams and change over time. A check that queries live compliance data enforces the current policy state without requiring the check itself to be updated every time the policy changes.

• Internal parametric and specifications data – engineering standards, preferred component specifications, internal datasheets, and test results that your organization maintains can be surfaced in Altium checks and panels, giving engineers access to internal knowledge at the point of decision.

Implementation Considerations

• Accessibility – a check that runs on the server-side platform needs to reach the external system from the server's network context. A check that runs client-side in Altium Designer needs to reach it from the engineer's machine. Confirm network accessibility before building checks that depend on external calls.

• Latency – desktop-side checks run while the engineer is working. A check that takes several seconds to return because of a slow external API creates friction engineers will route around. Keep external calls fast, targeted, and cacheable where the data doesn't change frequently.

• Failure handling – design checks to fail safely when the external system is unavailable. A check that can't reach the AVL should fail closed – report that it couldn't complete, not that the component is approved. Silently passing checks because the data source was unreachable is a reliability failure with compliance consequences.

• Authentication – external API calls from check logic need credentials. Store credentials as Workspace secrets or environment configuration, not hardcoded in check scripts. Treat check code as you would any production code that handles credentials.

What Custom Data Sources Are Not

Custom data sources in this context are calls from check and script logic – not a separate data integration layer or a sync mechanism. They do not replace Altium's built-in component data sources (Octopart, SiliconExpert, Z2Data) for supply chain and parametric data from external providers. They are the pattern for accessing your own internal systems from your own custom validation logic.

For use cases that require bidirectional data exchange between Altium 365 and external systems at the platform level – not just reads from check logic – the Altium 365 API and the PLM Integration SDK are the appropriate tools.