Baja API

The Baja API is where Niagara stops being configuration and becomes software engineering. It is Tridium’s Java framework underneath every station – components, points, histories, alarms, and drivers are all Baja objects. Software Pile develops against it directly: this is the practice’s core competency, led by a Tridium-certified Niagara Full Stack Developer.

What Baja Development Unlocks

• Custom components – typed objects with properties, actions, and topics that behave like native palette entries, slot sheets and all
• Custom drivers – full driver stacks: network, device, and proxy-point tiers for equipment Niagara has never heard of
• Services – station-level logic that runs continuously: schedulers, watchdogs, data processors, integration daemons
• Program logic beyond kitControl – when wire sheets hit their limits, compiled Baja logic takes over cleanly

Engineering Standards

Modules are developed against your exact Niagara version line, respect station lifecycle (steady-state starts, clean stops, license checks), handle fault conditions without wedging the station, and ship signed with third-party-certificate module signing. We document slot semantics so the next engineer – yours or ours – can maintain what we built.

Typical Baja Engagements

A driver for a proprietary chiller protocol. A component set an OEM ships with its hardware. A service that reconciles station data against an external system of record every night. If it lives inside the station and the palette cannot do it, it is probably a Baja project. Describe yours – include the Niagara version and target hardware.