Industrial IoT / SCADA · API

Eclipse Ditto HTTP API

Eclipse Foundation

Model and access connected things through a digital-twin HTTP interface.

Official documentation Download development spec

The linked unversioned Ditto pages identify themselves as development documentation. Pin a released version before implementing; do not assume every documented feature exists in your installation.

ECLIPSE DITTO / DEVELOPER FIELD GUIDE

Choose an interface. Define a verifiable result.

Company or project context, ten technical entry points and a practical analysis of every reference.

2026-10-08 · Integration not tested

Company / project overview

Original summary of official company or project statements; use the source for the full original page.

Eclipse Ditto · About
Project	Eclipse Ditto is an open-source, domain-independent digital twin framework for IoT devices.
Middleware role	It abstracts device state and exposes synchronous and asynchronous interfaces with resource-level access control.
Connectivity boundary	Device connectivity layers and protocol connections connect physical devices and external systems to Ditto.

Complete official About page ↗

About reference — TA analysis
Audience	Buyers, partners and product owners shortlisting an AI provider.
Our assessment	Use positioning and company history for initial fit. Obtain project-specific deployment, support and commercial terms separately.

Official sources reviewed; no live API, inference or benchmark was run. Expected results are proposed internal contracts.

Top 10 technical entry points

Ten documented technical entry points selected by developer task; not ten separate SDKs or an official ranking.

Choose by the work you need to complete
Interface	Purpose and audience
01 · Things modelAPI / SDK / developer guide	Represent a device as a digital twin entity.Twin model designers
02 · Features modelAPI / SDK / developer guide	Group device properties into features.Device capability modelers
03 · PolicyAPI / SDK / developer guide	Authorize access to twin resources.Access-control teams
04 · HTTP searchAPI / SDK / developer guide	Search authorized twins using filters.Fleet application developers
05 · HTTP messagesAPI / SDK / developer guide	Send application messages through Ditto.Device interaction teams
06 · WebSocket bindingAPI / SDK / developer guide	Exchange protocol messages over a persistent socket.Live UI teams
07 · Payload mappingAPI / SDK / developer guide	Translate external payloads to or from Ditto messages.Protocol integration engineers
08 · Twin and live channelsAPI / SDK / developer guide	Choose persisted twin access versus live device interaction.Architecture teams
09 · Conditional requestsAPI / SDK / developer guide	Apply updates only when declared conditions match.Concurrent update developers
10 · Acknowledgements and QoSAPI / SDK / developer guide	Define required acknowledgements for message processing.Delivery reliability engineers

Reference analysis

Capabilities summarize official documentation. Constraints and proposed tests are our engineering assessment.

API / SDK / developer guide

Things model

Things model · TA
Target audience	Twin model designers
Documented capability	Represent a device as a digital twin entity.
Input → output	Thing identifier and attributes → twin document.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Stored twin state may differ from the physical device.
Our suggested validation	Preserve device identity, update time and state provenance.

Official reference · Things model ↗

API / SDK / developer guide

Features model

Features model · TA
Target audience	Device capability modelers
Documented capability	Group device properties into features.
Input → output	Feature ID and properties → structured feature state.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Desired and reported properties are not interchangeable.
Our suggested validation	Validate property names, units and intended/reporting paths.

Official reference · Features model ↗

API / SDK / developer guide

Policy

Policy · TA
Target audience	Access-control teams
Documented capability	Authorize access to twin resources.
Input → output	Subjects, resources and permissions → enforced policy.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Authentication alone does not grant resource permissions.
Our suggested validation	Test allowed fields and denied cross-device access.

Official reference · Policy ↗

API / SDK / developer guide

HTTP search

HTTP search · TA
Target audience	Fleet application developers
Documented capability	Search authorized twins using filters.
Input → output	Query and fields → matching twin records.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Search results are subject to access control and pagination.
Our suggested validation	Check empty results and complete pagination without broadening access.

Official reference · HTTP search ↗

API / SDK / developer guide

HTTP messages

HTTP messages · TA
Target audience	Device interaction teams
Documented capability	Send application messages through Ditto.
Input → output	Message subject and payload → receiver response when available.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Message transport does not guarantee physical task completion.
Our suggested validation	Correlate device replies and handle timeout explicitly.

Official reference · HTTP messages ↗

API / SDK / developer guide

WebSocket binding

WebSocket binding · TA
Target audience	Live UI teams
Documented capability	Exchange protocol messages over a persistent socket.
Input → output	Subscribed or commanded protocol traffic → streamed responses/events.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Reconnect can interrupt event observation.
Our suggested validation	Reconcile state after reconnect rather than assuming no missed changes.

Official reference · WebSocket binding ↗

API / SDK / developer guide

Payload mapping

Payload mapping · TA
Target audience	Protocol integration engineers
Documented capability	Translate external payloads to or from Ditto messages.
Input → output	Device-specific payload → normalized protocol data.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Mapping errors can change units or target identifiers.
Our suggested validation	Round-trip representative payloads and reject malformed structures.

Official reference · Payload mapping ↗

API / SDK / developer guide

Twin and live channels

Twin and live channels · TA
Target audience	Architecture teams
Documented capability	Choose persisted twin access versus live device interaction.
Input → output	Channel-specific request → stored state or live response.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	A successful twin read is not proof the device is online.
Our suggested validation	Expose channel and data freshness to downstream users.

Official reference · Twin and live channels ↗

API / SDK / developer guide

Conditional requests

Conditional requests · TA
Target audience	Concurrent update developers
Documented capability	Apply updates only when declared conditions match.
Input → output	Condition and mutation → accepted update or failed precondition.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Ignoring failed conditions risks overwriting concurrent changes.
Our suggested validation	Test stale-state conflicts and retry only after reconciling current state.

Official reference · Conditional requests ↗

API / SDK / developer guide

Acknowledgements and QoS

Acknowledgements and QoS · TA
Target audience	Delivery reliability engineers
Documented capability	Define required acknowledgements for message processing.
Input → output	Requested acknowledgement labels → acknowledgement outcome.
Execution environment	Pinned released Ditto deployment and configured connectivity layer
Our decision constraint	Each acknowledgement covers a specific processing boundary.
Our suggested validation	Verify expected participants and distinguish missing acknowledgement from success.

Official reference · Acknowledgements and QoS ↗

HTTP API concepts

HTTP API concepts · Supporting reference analysis
TA	API integrators
Our validation advice	Choose the released-version documentation and confirm conditional access and response behavior.

Official reference · HTTP API concepts ↗

04 / INPUT · EXPECTED OUTPUT · ACCEPTANCE

Expected results before implementation

Illustrative digital-twin read contract, not native Ditto protocol JSON. No twin write, device message or API call was performed.

Illustrative contract · no API call or model execution · not measured provider output

Stored twin retrieved

Expected behavior — illustrative, not executed
Input	Authorized read of a known twin.
Expected result	ok with channel=twin and stored properties.
Acceptance	Preserve freshness and do not assert live device connectivity.

No search match

Expected behavior — illustrative, not executed
Input	Valid authorized search matches no twins.
Expected result	ok with things: [].
Acceptance	Distinguish search emptiness from denial and direct missing-resource errors.

Live device unavailable

Expected behavior — illustrative, not executed
Input	A live-channel request receives no device response within policy.
Expected result	timeout/error; stored twin may still be readable.
Acceptance	Never substitute stored data and label it live without disclosure.

Conditional update conflict

Expected behavior — illustrative, not executed
Input	Update condition does not match current twin state.
Expected result	error/conflict; do not report applied change.
Acceptance	Read current state and reconcile before any retry.

Map the expected result to your application

Map the actual SDK or service response into this proposed internal contract after integration. All IDs and values below are invented examples; no credentials or live requests are included.

Expected output JSON — illustrative, not measured · EclipseDitto-expected-results.json

{
  "schema_version": "1.0.0",
  "example": true,
  "provider": "Eclipse Ditto",
  "status": "ok",
  "input_id": "sample-001",
  "data": {
    "thing_id": "example:device",
    "channel": "twin",
    "reported": {
      "temperature_c": 24
    },
    "desired": {},
    "observed_at": null,
    "device_online_confirmed": false
  },
  "error": null,
  "verification": "illustrative-only;not-provider-response"
}

Download specification, example and acceptance plan

Engineering handoff — our proposed contract and gates
Result interpretation	Successful transport or execution does not establish model accuracy. Preserve valid empty results separately from operational failure.
Reproducibility	Record model, runtime, configuration and input identifiers; agree quality and latency criteria before representative tests. No measured performance is claimed.
Operation boundary	Illustrative digital-twin read contract, not native Ditto protocol JSON. No twin write, device message or API call was performed.

Development assessment

Device state twin

Development concept · integration not tested

Provider capabilities above are based on official documentation or repositories. The proposed product, inputs, deliverable and acceptance criteria below are our development assessment.

Small prototype

Test one documented operation with a small real sample after access is confirmed. This is a development judgment, not a delivery estimate.

Proposed inputs: A test device or simulator, a tag map and documented units.
Proposed deliverable: Timestamped device values with freshness, unit and connection state.
Acceptance criterion: Verify scaling and timestamps against the source; a disconnected device must not appear healthy.
Dependencies: A gateway or service account, an equipment schema and access to a test environment.

Integration condition

The linked unversioned Ditto pages identify themselves as development documentation. Pin a released version before implementing; do not assume every documented feature exists in your installation.

Development sequence

Confirm access to Eclipse Ditto HTTP API, license and the exact supported version.
Prepare the sample above and implement one documented operation for “Device state twin”.
Normalize the result with source, time and explicit error state; keep the provider response for review.
Run the acceptance criterion before estimating rollout effort or committing a customer deliverable.

How to validate demand

Record product views, documentation clicks, specification downloads and contextual hub clicks. These are event counts, not unique people or completed integrations.

This feasibility assessment uses implementation conditions. No traffic-based rank or delivery-time promise is assigned.

Eclipse Ditto HTTP API

Choose an interface. Define a verifiable result.

Company / project overview

Top 10 technical entry points

Reference analysis

HTTP API concepts

Expected results before implementation

Stored twin retrieved

No search match

Live device unavailable

Conditional update conflict

Map the expected result to your application

Device state twin

Integration condition

Development sequence

How to validate demand

Related products