API & data sources
Drive · CMMS · custom
Not all data lives in an instrument export. Niobia connects to where teams already keep their files and systems: Google Drive is available on the public platform today, and API-based integrations into CMMS and other systems are built custom for early customers.
What it measures
Process and quality data accumulates in more places than the tester. A complete integration reaches the systems of record and the file stores teams actually use:
- Cloud file storage: the shared drives where labs already park their exports, spreadsheets, and reports. Connecting here means analysis starts from where the data lives, with no manual download-and-upload step.
- Maintenance and quality systems (CMMS, and similar): equipment history, work orders, and maintenance records are evidence in a root-cause investigation, and bringing them alongside process and materials data is what lets a correlation include "what was serviced when."
- Generic APIs: the long tail of internal systems a given plant runs, reached through API integrations rather than a fixed connector list.
As with every integration in this branch, the relationship is read and analyze. The source systems stay the source of truth; Niobia reads from them.
How to read the output
The useful question is what is generally available versus what is bespoke. File storage through Google Drive is live on the public platform: any team can point Niobia at the drive where their data already sits. CMMS and other API integrations are built custom for early customers, because the systems and schemas differ enough per plant that a one-size connector would not be honest. Read these pages for that distinction: a self-serve capability you can use today, and a custom-engineering path for the systems that need it, rather than a blanket claim that every system is already wired.
A real use case
A research team keeps every cycling export in a shared Google Drive folder organized by project. Instead of downloading files and re-uploading them one at a time, they connect the drive once, and Niobia analyzes the data where it already lives, new exports included as they land. Separately, a manufacturing customer wants equipment maintenance history in the loop, so a downtime or service event can line up against a defect trend: that CMMS integration is built for them through its API, because their maintenance system and schema are specific to their plant. Two different integration modes, one self-serve and one custom, both feeding the same analysis layer.
Common mistakes
- Treating every data source as self-serve. File storage is; deep system integrations like CMMS are custom work, and pretending otherwise oversells the connector.
- Leaving maintenance and equipment history out of root-cause work. "What was serviced when" is often the missing column in a batch correlation.
- Re-downloading and re-uploading files manually when the storage could be connected once and read directly.
- Expecting Niobia to become the system of record. It reads from these systems; they stay authoritative.
Connect to the data where it already lives
On the public platform, Niobia connects to Google Drive today, so analysis can start from the shared storage a team already uses rather than from a manual upload. Beyond file storage, API-based integrations into CMMS and other plant systems are built custom for early customers, because maintenance and quality systems and their schemas vary enough per site that a real integration is engineered, not toggled. Both modes feed the same analysis layer and follow the same boundary as the rest of this branch: Niobia reads from these systems and analyzes the data; it does not become the system of record, and it does not write back into the customer's source of truth, the same read-not-rewrite stance the architecture takes toward the ledger.
Frequently asked
What data-source integrations are available right now?
Google Drive is available on the public platform today: connect the drive where your exports and files already live and Niobia analyzes them in place. Deeper system integrations (CMMS and other APIs) are built custom for early customers.
Why are CMMS and API integrations custom rather than self-serve?
Because maintenance and quality systems, and their schemas, differ substantially between plants. A genuine integration into a specific CMMS is engineered for that system; a generic one-click connector would either be shallow or misleading. For early customers, Niobia builds these directly.
Does connecting a data source give Niobia write access?
No. The integration is read-and-analyze. The source systems remain authoritative and Niobia reads from them, consistent with the architecture's stance that the system of record is never the agent's to rewrite.