Written for the engineer evaluating whether this fits, not for a brochure. Concepts and workflow here; full reference travels with credentials so it cannot go stale.
These pages cover the parts of integration that are stable: how a device is connected and decoded, what the integration surfaces are, and which one fits which job. They contain no endpoint URLs, no authentication detail and no code samples, because those change and a public page describing them goes quietly wrong.
If you are evaluating the platform, this should be enough to tell whether it fits your architecture. If you are building against it, ask for access and you will get the versioned reference plus sandbox credentials.
Questions these do not answer are the useful ones. Send them over or message us on WhatsApp.
Because a published reference drifts out of date and confidently wrong documentation wastes more of an integrator's time than none. The full reference is versioned with the API and issued alongside credentials; these pages cover the parts that do not change.
Integrators, technical buyers and installers deciding whether the platform fits before anyone signs anything. They are deliberately conceptual rather than a manual.
Ask. There is no gate beyond being a customer or a partner building against the platform, and we issue sandbox credentials so integration work can start before a production account exists.
Tell us what you are integrating and we will issue sandbox credentials and the full reference.
Request API Access →