Industrial IoT / SCADA · API / SDK

Azure IoT Hub REST API

Microsoft

Integrate device and service operations through IoT Hub interfaces.

Official documentation Download development spec

AZURE IOT HUB / 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.

Azure IoT Hub · About
Service	Microsoft Azure IoT Hub is a managed device-to-cloud messaging and device-management integration service.
Boundaries	Telemetry, desired configuration, command replies and file uploads have distinct completion criteria; hub tiers and client support determine available features.

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 provider API or inference was run; results are illustrative internal contracts.

Top 10 technical entry points

Ten documented technical entry points selected for implementation decisions, not ten independent SDKs or an official ranking.

Choose by the work you need to complete
Interface	Purpose and audience
01 · REST API familiesAPI / SDK / developer guide	Separate service, device messaging and resource management APIs.Backend integrators
02 · Device/service/management SDKsAPI / SDK / developer guide	Choose SDK for device, backend or hub resource management.SDK implementers
03 · Device twinsAPI / SDK / developer guide	Synchronize desired and reported properties.Device configuration teams
04 · Direct methodsAPI / SDK / developer guide	Invoke device-defined request/reply operations.Interactive control developers
05 · Message routingAPI / SDK / developer guide	Filter telemetry/events into built-in or custom endpoints.Telemetry pipeline teams
06 · Cloud-to-device messagesAPI / SDK / developer guide	Queue one-way notifications for individual devices.Notification integrators
07 · Identity registryAPI / SDK / developer guide	Manage identities permitted to connect.Fleet identity engineers
08 · Scheduled jobsAPI / SDK / developer guide	Schedule operations across device selections.Fleet operators
09 · Microsoft Entra service accessAPI / SDK / developer guide	Authorize service access with Entra identities and roles.Cloud security teams
10 · File uploadsAPI / SDK / developer guide	Coordinate device uploads into linked Blob Storage.Large telemetry/media teams

Reference analysis

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

API / SDK / developer guide

REST API families

REST API families · TA
Target audience	Backend integrators
Documented capability	Separate service, device messaging and resource management APIs.
Input → output	Versioned HTTPS requests → response and request ID.
Execution environment	Hub endpoint, API-specific version and authorization.
Our decision constraint	Do not reuse one overview API version across all operations.
Our suggested validation	Follow operation-specific schema and ETag semantics.

Official reference · REST API families ↗

API / SDK / developer guide

Device/service/management SDKs

Device/service/management SDKs · TA
Target audience	SDK implementers
Documented capability	Choose SDK for device, backend or hub resource management.
Input → output	Typed calls → telemetry, state or management responses.
Execution environment	Pin SDK and platform support; use embedded SDK for constrained devices.
Our decision constraint	Unified Azure IoT SDKs are listed as preview, not assumed production replacement.
Our suggested validation	Confirm protocol and feature support of the selected language package.

Official reference · Device/service/management SDKs ↗

API / SDK / developer guide

Device twins

Device twins · TA
Target audience	Device configuration teams
Documented capability	Synchronize desired and reported properties.
Input → output	JSON desired update → reported application state.
Execution environment	Standard-tier feature; device and service permissions differ.
Our decision constraint	Latest reported properties are not a complete time-series audit.
Our suggested validation	Check version, ETag and fresh device acknowledgement.

Official reference · Device twins ↗

API / SDK / developer guide

Direct methods

Direct methods · TA
Target audience	Interactive control developers
Documented capability	Invoke device-defined request/reply operations.
Input → output	Method name and JSON → device status/payload or timeout.
Execution environment	Standard tier; HTTPS service and supported device protocol.
Our decision constraint	Ordering/concurrency is not guaranteed; timeout is not cancellation proof.
Our suggested validation	Evaluate device application status as well as transport status.

Official reference · Direct methods ↗

API / SDK / developer guide

Message routing

Message routing · TA
Target audience	Telemetry pipeline teams
Documented capability	Filter telemetry/events into built-in or custom endpoints.
Input → output	Message and route condition → destination delivery.
Execution environment	Destination write access and sufficient throughput.
Our decision constraint	Matching multiple routes is not arbitrary business exactly-once processing.
Our suggested validation	Check matching and nonmatching messages plus destination health.

Official reference · Message routing ↗

API / SDK / developer guide

Cloud-to-device messages

Cloud-to-device messages · TA
Target audience	Notification integrators
Documented capability	Queue one-way notifications for individual devices.
Input → output	Device-bound message → lifecycle and feedback.
Execution environment	Standard tier; protocol-specific settlement behavior.
Our decision constraint	At-least-once delivery requires idempotence; MQTT cannot reject or abandon.
Our suggested validation	Distinguish message completion from long-running business completion.

Official reference · Cloud-to-device messages ↗

API / SDK / developer guide

Identity registry

Identity registry · TA
Target audience	Fleet identity engineers
Documented capability	Manage identities permitted to connect.
Input → output	Device/module identity → registry record.
Execution environment	Hub registry permissions and device authentication.
Our decision constraint	Registry membership is not evidence of current connectivity.
Our suggested validation	Verify exact identity and enabled/authentication configuration.

Official reference · Identity registry ↗

API / SDK / developer guide

Scheduled jobs

Scheduled jobs · TA
Target audience	Fleet operators
Documented capability	Schedule operations across device selections.
Input → output	Job target query and operation → per-device job outcomes.
Execution environment	Compatible hub tier and service permissions.
Our decision constraint	Scheduled or accepted is not fleet-wide completion.
Our suggested validation	Reconcile intended targets, successes and failures.

Official reference · Scheduled jobs ↗

API / SDK / developer guide

Microsoft Entra service access

Microsoft Entra service access · TA
Target audience	Cloud security teams
Documented capability	Authorize service access with Entra identities and roles.
Input → output	Identity token and assigned roles → authorized data operations.
Execution environment	Configured tenant identity and appropriate IoT Hub role.
Our decision constraint	Service authorization is separate from device credentials.
Our suggested validation	Exercise least-privileged allowed and denied actions.

Official reference · Microsoft Entra service access ↗

API / SDK / developer guide

File uploads

File uploads · TA
Target audience	Large telemetry/media teams
Documented capability	Coordinate device uploads into linked Blob Storage.
Input → output	Upload initialization → SAS URI; blob upload → completion notification.
Execution environment	Linked storage/container, network access and expiring SAS.
Our decision constraint	Receiving a SAS URI does not mean bytes were uploaded.
Our suggested validation	Verify blob size/hash and correlate completion; never expose SAS.

Official reference · File uploads ↗

Official documentation

Official documentation · Supporting reference analysis
TA	Developers and technical product owners
Our validation advice	Pin the release and follow the target-specific support requirements before implementation.

Official reference · Official documentation ↗

04 / INPUT · EXPECTED OUTPUT · ACCEPTANCE

Expected results before implementation

Proposed device configuration and delivery contract, with invented examples only. No Azure requests, credentials or devices were used.

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

Configuration applied

Expected behavior — illustrative, not executed
Input	Desired telemetry interval updated; fresh device report matches.
Expected result	application_acknowledged=true with correlated version.
Acceptance	Require reported application evidence, not only successful twin PATCH.

No matching fleet members

Expected behavior — illustrative, not executed
Input	Valid target query returns zero devices.
Expected result	targets=[]; no device operations started.
Acceptance	Show valid empty selection rather than fleet-wide success.

Direct method timeout

Expected behavior — illustrative, not executed
Input	Device does not reply before configured response deadline.
Expected result	Timed out; physical outcome unknown.
Acceptance	Do not assume rollback; reconcile state before retrying a non-idempotent command.

Upload initialized but incomplete

Expected behavior — illustrative, not executed
Input	SAS granted but blob transfer fails.
Expected result	upload_complete=false; preserve correlation ID and error.
Acceptance	No completed-file event in internal contract until content is verified.

Map the expected result to your application

Map your actual runtime response into this proposed application contract. All values are invented examples; no credentials or live execution are included.

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

{
  "schema_version": "1.0.0",
  "example": true,
  "provider": "Azure IoT Hub",
  "status": "ok",
  "input_id": "sample-001",
  "data": {
    "device_id": "demo-device-001",
    "desired_interval_seconds": 60,
    "reported_interval_seconds": 60,
    "reported_version_matches": true,
    "application_acknowledged": true
  },
  "error": null,
  "verification": "illustrative-only;not-provider-response"
}

Download specification, example and acceptance plan

Engineering handoff — our proposed contract and gates
State semantics	Valid empty results differ from errors. Pending work must not appear successful before completion.
Evidence	Record service and SDK versions, request identity, configuration and response mapping. No execution or performance was measured here.
Acceptance proposal	Agree numerical tolerances and workload targets before testing on representative authorized samples.

Development assessment

Device-status workspace

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.

Integration pilot

Validate runtime, schemas or hardware together before estimating a deployable product.

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.

Development sequence

Confirm access to Azure IoT Hub REST API, license and the exact supported version.
Prepare the sample above and implement one documented operation for “Device-status workspace”.
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.

Azure IoT Hub REST API

Choose an interface. Define a verifiable result.

Company / project overview

Top 10 technical entry points

Reference analysis

Official documentation

Expected results before implementation

Configuration applied

No matching fleet members

Direct method timeout

Upload initialized but incomplete

Map the expected result to your application

Device-status workspace

Development sequence

How to validate demand

Related products