Neowit developer docs
API referenceSupportKnowledge baseStatusApp
  • Overview
  • REST API
    • Introduction
    • Authentication
      • OAuth2
      • Basic Auth
    • Error codes
    • API reference
    • Coordinate systems
    • Query Language
      • Query Language Reference
  • Service Accounts
    • Introduction
    • Creating service accounts
  • Integrations
    • Introduction
    • MQTT
      • Native Sparkplug
      • Custom Starlark
  • Starlark
    • Introduction
    • Modules
      • time module
      • json module
      • math module
      • devices module
      • series module
      • sensors module
  • Tutorials
    • Introduction
    • Create users using API
Powered by GitBook
On this page
  • Introduction
  • Organizations
  • Users
  • Service accounts
  • Spaces
  • Integrations
  • Devices
  • Workspaces
  • Bookings

Overview

A quick overview for developers.

NextIntroduction

Last updated 3 months ago

Introduction

On this page, we will introduce some core concepts used throughout the platform. For a full overview of our s, see the .

Organizations

An organization represents the main grouping entity within the Neowit platform. All other entities within the API are owned by an organization. An organization may have child organizations; supporting use-cases such as resellers, partners, distributors etc.

Users

A user account represents a person and requires an email. Authentication is done using email and password or Single Sign-On (SAML). A user belongs to an organization and can have role of Member or Administrator. Currently, a Member is granted access to the Workspace application, while Administrators have additional access to administrating Organizations, Users, Spaces, Integrations, Dashboards and Workspaces.

Service accounts

A Service Account represents an machine account which is suitable for creating custom integrations. See for more details.

Spaces

A Space represents entities of a building. A Space has a name, type and optional children; forming a hierarchical tree of spaces where the root would typically represent the building, the first level of children would represent the floor and second level typically represents objects on the floor such as rooms, desks and so on.

Each Space is given a geometry, which is used to form the current 2D floorplans. Currently, we recommend using the editor in the App to control these Spaces. If you want to get your hands dirty with this, look at Coordinate systems.

Integrations

Devices

Workspaces

Bookings

Devices are managed by Integrations, and can represent a physical or virtual device. A device can provide a collection of SensorTypes, denoting different types of metrics that can be ingested or queried. A Device may optionally be associated with a Space (e.g., temperature sensor in Room1), and can be given a Point location to make it easier physically find the device.

REST API
API reference
Service Accounts
GeoJSON
GeoJSON