Standard Connectors

The developer path into DriftMind. Native REST API, official Python SDK, and native Kafka ingestion — the same contract on SaaS, Edge, and Enterprise. Whichever target you point at, the code is identical.

View on GitHub Developer Guide

Three Ways In

Pick the integration model that fits your stack. All three speak the same DriftMind data model and respect the same authentication, quota, and capability rules.

REST API

The canonical interface. OpenAPI 3.0 documented. Token authentication. Powers every other connector and SDK underneath. The same endpoints serve SaaS, Edge, and Enterprise deployments.

/api/driftmind/v1 · OpenAPI 3.0 · token auth

Python SDK

Official Python client wrapping the REST API. Capability-aware — automatically detects which features (forecasting, anomaly detection, Echo) are available on the target deployment.

driftmind-client · pip-installable · sync & async

Kafka Ingestion

Subscribe DriftMind directly to your Kafka topics. Configurable consumer groups, partition strategy, and offset handling. Backpressure-aware for high-throughput streams.

native consumer · per-forecaster topic mapping

REST API

The canonical interface

Every other connector — SDK, third-party integrations, internal tooling — sits on top of the REST API. It's documented in OpenAPI 3.0, served from /api/driftmind/v1, and uses bearer token authentication via an Auth header.

The same endpoint contract is honoured across SaaS, Edge, and Enterprise. URL prefix and authentication change; payloads do not.

Use the REST API directly when you're integrating from a language without an official SDK, or when you need fine-grained control over batching, retries, or auth.

# Create a forecaster
$ curl -X POST https://api.thingbook.io/api/driftmind/v1/forecasters \
    -H "Auth: $TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "forecasterName": "pump-monitor",
      "features": ["temperature", "vibration"],
      "inputSize": 30,
      "outputSize": 1
    }'

# Stream observations
$ curl -X POST .../forecasters/{id}/observations \
    -H "Auth: $TOKEN" \
    -d '{"temperature":[22.1,22.3],"vibration":[0.5,0.6]}'

# Get predictions + anomaly + Echo matches
$ curl .../forecasters/{id}/predictions \
    -H "Auth: $TOKEN"

Python SDK

Capability-aware by design

The Python client wraps the REST API in idiomatic Python and adds capability negotiation. On construction, the client queries the target deployment to learn which features are available. Calling Echo on a deployment that doesn't support it raises a clear EchoNotAvailableError rather than failing silently.

The same code runs against the SaaS endpoint, a local Edge container, or an Enterprise on-prem deployment. Swap the base_url, keep the rest.

Both synchronous and async variants are available. Sync for scripts, batch jobs, and notebooks; async for high-throughput streaming integrations.

# Install
$ pip install driftmind-client

# Use against SaaS
from driftmind import DriftMindClient

client = DriftMindClient(
    base_url="https://api.thingbook.io",
    token="...",
)

forecaster = client.forecasters.create(
    name="pump-monitor",
    features=["temperature", "vibration"],
    input_size=30,
)

forecaster.feed({
    "temperature": [22.1, 22.3],
    "vibration":   [0.5, 0.6],
})

predictions = forecaster.predict()

# Same code against Edge — only base_url changes
client = DriftMindClient(base_url="http://localhost:8080")

Native Kafka Ingestion

For high-throughput streaming

When you're already publishing telemetry to Kafka — from mediation layers, IoT gateways, or upstream services — DriftMind can subscribe directly. Each forecaster is mapped to one or more topics, and incoming messages are decoded, batched, and fed into the engine.

The native Kafka consumer is consumer-group aware (so you can scale horizontally) and handles backpressure gracefully — DriftMind never causes the broker to fall behind because of slow downstream processing.

Configure topic-to-feature mapping, partition strategy, and offset behaviour through the standard Forecaster config. No external connector, no additional infrastructure.

# Create a forecaster bound to a Kafka topic
$ curl -X POST .../forecasters \
    -H "Auth: $TOKEN" \
    -d '{
      "forecasterName": "fleet-pressure",
      "features": ["psi"],
      "inputSize": 60,
      "ingestion": {
        "type": "kafka",
        "brokers": "kafka.internal:9092",
        "topic": "plant.sensors.psi",
        "consumerGroup": "driftmind-fleet-pressure",
        "messageFormat": "json",
        "valuePath": "$.reading.value",
        "timestampPath": "$.reading.ts"
      }
    }'

# Observations now arrive directly from Kafka.
# Predictions are still fetched via REST or SDK.
$ curl .../forecasters/{id}/predictions

Why It Matters

One Contract, Every Tier

SaaS, Edge, Enterprise — same API, same SDK, same Kafka semantics. The code you write in your dev sandbox is the code that ships to production, regardless of where DriftMind lives.

Capability-Aware

The SDK queries the deployment for available features at construction time. Echo, anomaly detection, forecasting — your code knows what's available before it tries to use it. No silent failures.

No Extra Infrastructure

The native Kafka consumer lives inside DriftMind. No Kafka Connect cluster to manage, no schema registry to integrate with separately, no extra container in your deployment topology.

Start Building

Free 30-day SaaS access lets you exercise the full REST API, install the SDK, and stream observations from a local Kafka — no infrastructure to set up.

Start Free Developer Guide