Tenix Open Data Platform API - Documentation

The Tenix Open Data Platform operates across multiple domains, forming the foundational structure for delivering the Tenix Products. These domains are integral to the API's infrastructure, facilitating the potential for comprehensive API integration within the scope of the provided data. Below is a non-exhaustive list of domains currently established within the Tenix Open Data Platform, all of which are accessible for integration through the API:

• Device Metadata - device registry
• Vehicle Metadata - vehicle registry
• Vehicle Telemetry - telemetry coming from the vehicles, through the devices
• Vehicle Schedule - logistics/scheduling processes
• Journey - recorded journeys with data aggregations (ex. consumptions)
• Charging - processes related to electric vehicles charging
• Organization - customers organization structure representation
• Account - user information
• Notifications/Alarms

While the APIs are stable, they are components that evolve rapidly in response to changing business situations. Saga Tenix employs IT best practices to adapt to the context and characteristics of the provided data. These practices include offering various:

• API Access Patterns: For example, push for real-time data versus pull for historical data.
• API Protocols: Utilizing different protocols best suited for the data and use cases.
• API Interoperability: Ensuring APIs can work seamlessly with different systems and services.
• API Complementarity: Designing APIs to enhance and complement the capabilities of existing systems.

Etc.

These practices cover a range of considerations, from security to scalability, and from documentation to community support. As part of continuous improvement and in alignment with IT best practices, the shape of the API may undergo changes in the future to better serve user needs and to align with technological advancements.

The Tenix Open Data Platform API is crafted to accommodate various customer scenarios, adapting the data delivery method to suit the data's characteristics. It categorises data into two main kinds: historical data and real-time data.

ℹ️ Info - for obtaining the username and password, please contact sales@tenix.eu

The API is secured by default. In order to use the API, a valid JWT token has to be generated.

To generate a token, use the following POST request:

curl -X POST "https://openapi.platform.tenix.eu/auth" \
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=<username>&password=<password>&scope=openapi&grant_type=password"

The server will respond with a valid token. The token has a validity period, once it expires, it has to be obtained again.

Example Response:

  {
    "access_token": "your-token",
    "token_type": "Bearer",
    "expires_in": 86400
  }

Notes:

• Tokens expire in 1 day, so ensure they are refreshed as needed.
• Always keep your token secure to prevent unauthorized access.

Historical data provides the status of each domain object at a specific moment in the past. It possesses a relatively static nature, remaining unchanged over time with an indefinite validity period. Customers can request this data at any time, and they will consistently receive identical information as long as the querying criteria remain the same.

• Technology: GraphQL
• Documentation: https://tenix.tech/graphql
• Auth: Place the JWT Token in the Authorization: Bearer <token> header.

Real-time data exhibits a distinct nature compared to historical data. It remains valid only when it is up-to-date, typically for a very brief period. Due to this, Tenix has opted for a push model based on the publish-subscribe integration pattern for information delivery. Clients subscribing to specific domain updates receive immediate notifications about any changes.

• Technology: MQTT
• Documentation: https://tenix.tech/mqtt
• Auth: Place the JWT Token in the user field of the connection. Leave the password blank.

MQTT by design does not provide retention (at least meaningful from storage perspective) on data being published on the topics. Such solution is much more lightweight than e.g. Apache Kafka and suits better the realtime nature of the data it processes.