SDS types

An SDS type (also known as a stream type in the CONNECT portal) defines the schema for data points written to streams. It specifies data point properties, property data types, and the property (or properties) that form the primary key, which uniquely identifies each data point in a stream.

You can think of an SDS type as a blueprint. It defines what each data point (a single data record) must contain before that data point is stored in a stream (an ordered collection of data points that share an SDS type).

For example, a telemetry SDS type might define Time, Temperature, and Pressure properties. Every data point written to a stream that uses this SDS type follows that shape.

This example represents a simple telemetry SDS type definition with one key property (Time) and two non-key measurement properties (Temperature and Pressure).

{

"id": "TelemetryType",

"sdsTypeCode": "Object",

"properties": [

{

"id": "Time",

"sdsType": {

"id": "DateTimeType",

"sdsTypeCode": "DateTime"

},

"isKey": true

},

{

"id": "Temperature",

"sdsType": {

"id": "DoubleType",

"sdsTypeCode": "Double"

},

"isKey": false

},

{

"id": "Pressure",

"sdsType": {

"id": "DoubleType",

"sdsTypeCode": "Double"

},

"isKey": false

}

]

}

After this SDS type is defined, you can create a stream that references it (for example, by setting the stream typeId to TelemetryType).

From that point on, every data point written to the stream must match the SDS type shape and key rules:

• The data point must include Time, Temperature, and Pressure.

• Time acts as the key value used for ordering and uniqueness in the stream.

For example, a valid data point written to that stream could look like this:

{

    "Time": "2026-03-09T12:00:00Z",

    "Temperature": 24.5,

    "Pressure": 101.7

}

As additional data points are written with different Time values, the stream builds an ordered data point sequence such as:

Note on the term "type"

Type is a loaded term in the context of Stream Management, and there are some variations of the use of the term. SDS type refers to the SdsType schema resource, the main topic of this document. Primitive type refers to a property-level value type such as String, Int32, or DateTime, which is used by properties within an SDS type. In this topic, when "type" is used without a qualifier, it usually refers to an SDS type rather than a primitive type.

Required properties for an SDS type

When you call Create type definition (POST /api/v2/Types/{typeId}), the request body is an SdsType object.

Required top-level fields are:

• id: Unique type identifier.

• sdsTypeCode: Base SDS type code (for most data point schemas, this is Object).

• properties: Collection of property definitions for the data point schema.

Within properties, each property definition should include:

• id: Property identifier.

• sdsType: Property data type (sdsTypeCode is defined here).

• isKey: Marks whether the property participates in the primary index.

At least one property must be marked with isKey: true so data points can be uniquely indexed in streams that use this SDS type. For inheritance behavior (including key inheritance through baseType), see Reuse and composition below.

Note: These required properties are described in more detail in SDS type property fields and other headings below.

Example request body

{

"id": "SimpleType",

"sdsTypeCode": "Object",

"properties": data point

{

"id": "Time",

"sdsType": {

"sdsTypeCode": "DateTime"

},

"isKey": true

},

{

"id": "Measurement",

"sdsType": {

"sdsTypeCode": "Double"

},

"isKey": false

},

{

"id": "State",

"sdsType": {

"sdsTypeCode": "Int32"

},

"isKey": false

}

}

Common optional fields include:

• name and description.

• interpolationMode and extrapolationMode.

For the complete request-body schema, see SdsType in Stream Management.

SDS type ID rules

The type identifier in id follows these rules:

• It is not case sensitive.

• It cannot be only whitespace.

• It cannot contain leading or trailing whitespace.

• It cannot contain /.

• It can have at most 250 characters.

Keys and indexes

A stream's SDS type must include at least one key property (isKey: true). That key defines the stream's primary index. When using baseType, the key can come from the base type (for more information, see Reuse and composition(reuse-and-composition)). Base type properties are resolved as inherited properties during validation, so the derived type does not need to define its own key property.

For complete index behavior and examples, see Indexes, especially:

• Primary indexes

• Compound indexes

• Compound index data point sorting and order

• Supported property data types for indexes

SDS type property fields

Each entry in properties defines one field in the data point schema.

Key property fields include:

• id: Property identifier.

• sdsType: Data type for the property.

• isKey: Marks the property as part of the primary index. In a single-index SDS type, one property has isKey: true. In a compound index, each key property has isKey: true.

• order: Comparison order in compound indexes.

Additional property fields include value (for enum values), interpolationMode, and uom.

The following example emphasizes the properties object. Focus on how each property entry defines identity, data type, key participation, ordering, and optional property behavior.

{

    "id": "EquipmentTelemetryType",

    "sdsTypeCode": "Object",

    "properties": [

        {

            "id": "Time",

            "sdsType": {

                "sdsTypeCode": "DateTime"

            },

            "isKey": true,

            "order": 0

        },

        {

            "id": "Temperature",

            "sdsType": {

                "sdsTypeCode": "Double"

            },

            "isKey": false,

            "interpolationMode": 0,

            "uom": "degree Celsius"

        },

        {

            "id": "State",

            "sdsType": {

                "sdsTypeCode": "Int16Enum"

            },

            "isKey": false,

            "value": 0

        }

    ]

}

For full details, see the SdsTypeProperty schema in Stream Store.

SdsTypeCode and supported types

SdsTypeCode identifies the underlying SDS data type. Primitive types are fully defined by SdsTypeCode, while more complex types can require additional property details.

For the complete supported type list, see the SdsTypeCode schema in Stream Management. SdsTypeCode values are typically passed as string names in (for example, "Int32Enum"), though the underlying model uses an integer-backed enum and numeric values may also be accepted by the serializer.

This example defines an enum SDS type named State. The top-level sdsTypeCode must be an enum type code (such as Int32Enum). This code is what tells the server to treat the type as an enum. Each entry in properties defines a named enum value using id and value.

{

"id": "State",

"sdsTypeCode": "Int32Enum",

    "properties": [

        {

            "id": "Ok",

            "value": 0

        },

        {

            "id": "Warning",

            "value": 1

        },

        {

            "id": "Alarm",

            "value": 2

        }

    ]

}

Units of measure on type properties

You can assign a unit of measure (UOM) to any numeric SdsTypeProperty using the uom field. When a property has a UOM assigned, Stream Store can convert property values to different units during read operations without modifying stored data. The UOM you specify must exist in the system-defined Stream Store catalog, and the server resolves it by ID, name, or abbreviation.

For the full UOM and quantity catalog, conversion behavior, stream-level overrides, and read-time conversions, see Units of measure and Quantities reference.

Reuse and composition

An SDS type can reuse another SDS type through baseType and can participate in inheritance through derivedTypes.

Common reuse patterns include:

• Defining a base SDS type with shared key and common properties, then creating specialized SDS types that add domain-specific properties.

• Referencing a base SDS type by ID only in baseType when that base type already exists.

• Sending a full baseType definition when needed. If the referenced type does not exist, Stream Management can create it during type creation.

When you create or validate a type with Create type definition (POST /api/v2/Types/{typeId}), ensure the resulting SDS type has at least one valid key property. That key can be inherited from the base SDS type.

The following request payload example creates a derived SDS type named PumpTelemetryType by referencing an existing base type (EquipmentBaseType) and adding pump-specific properties for vibration and oil temperature.

{

    "id": "PumpTelemetryType",

    "name": "Pump telemetry type",

    "description": "Derived telemetry type for pump health monitoring.",

    "sdsTypeCode": "Object",

    "baseType": { // Reuses an existing SDS type as the base schema

        "id": "EquipmentBaseType" // References the base type by its ID

    },

    "properties": data point

        {

            "id": "VibrationRms",

            "sdsType": {

                "sdsTypeCode": "Double"

            },

            "isKey": false

        },

        {

            "id": "OilTemperature",

            "sdsType": {

                "sdsTypeCode": "Double"

            },

            "isKey": false

        },

        {

            "id": "OperatingState",

            "sdsType": {

                "sdsTypeCode": "String"

            },

            "isKey": false

        }

    ]

}

Read behavior settings

SDS type settings influence read behavior for missing index values through interpolation and extrapolation rules.

For example, a request for a timestamp between two stored data points can return an interpolated value depending on configured modes.

For more information, see .

Type immutability and versioning

SDS types are immutable after creation. To change a type definition, create a new SDS type and migrate usage. For example, if you need to add a required property, create a new SDS type with a new id and update streams to use it.

Type management operations

After creation, SDS types persist as managed resources in your Stream Management instance. They may accumulate dependencies (streams using them), access restrictions, and ownership configurations. You need operational endpoints to discover what types exist, understand their dependencies, manage lifecycle (including safe deletion), and control access.

The API supports:

• Listing and retrieving types with GET /api/v2/Types and GET /api/v2/Types/{typeId}.

• Creating (or validating existing compatibility) with POST /api/v2/Types/{typeId}.

• Deleting with DELETE /api/v2/Types/{typeId} when no dependencies exist.

• Checking dependencies with GET /api/v2/Types/{typeId}/ReferenceCount.

You can also manage type-level security and ownership with:

• GET|PUT|PATCH /api/v2/Types/{typeId}/SecurityTags.

• GET|PUT /api/v2/Types/{typeId}/Owner.