generated: '2026-09-09' method: searched source: openapi/_original/aedifion-openapi.json docs: - https://docs.aedifion.io/en/developers/mqtt-api/ - https://docs.aedifion.io/en/developers/kafka/ note: >- aedifion has an unusually broad event surface for a building platform - three distinct streaming/push mechanisms - but publishes no AsyncAPI, no CloudEvents binding and no subscribable webhook catalog. This file inventories what actually exists. surfaces: - kind: mqtt status: published generally_available: true broker: mqtt.aedifion.io ports: [8883, 9001] tls_only: true tls_versions: [TLSv1.2, TLSv1.3] protocol_version: MQTT 3.1.1 qos: [0, 1, 2] topics: - 'timeseries: /' - 'metadata: META//' - 'controls: CONTROLS//' payloads: timeseries: InfluxDB Line Protocol metadata: JSON, max 1 MB, scheme V2 (V1 deprecated) controls: JSON, SWOP protocol auth: username/password in CONNECT, per-topic read/write authorization spec: asyncapi/aedifion-mqtt-asyncapi.yml reachability: dns: resolves a_record: 94.130.225.123 note: >- mqtt.aedifion.io resolves to the same Hetzner address as api.aedifion.io and auth.aedifion.io. Ports 8883 and 9001 were NOT reachable from the probe host, so the TLS handshake could not be observed. That is a limitation of this probe's network egress, not evidence about the broker - the broker is credential-gated in any case and could not have been exercised anonymously. probed: '2026-09-09' spec_provenance: generated by API Evangelist from the published MQTT docs docs: https://docs.aedifion.io/en/developers/mqtt-api/ - kind: kafka status: published generally_available: unclear note: >- The edge device documentation marks Kafka as "partially available on demand". No production bootstrap server hostname is published - the docs show only a placeholder "My_bootstrap_servers:9092" - so a consumer cannot connect from public information alone. port: 9092 auth: SASL/SCRAM-SHA-512 with security_protocol SSL topics: - 'observations: mtw.aed.{project_handle}.data' - 'metadata: mtw.aed.{project_handle}.metadata' payload: InfluxDB Line Protocol docs: https://docs.aedifion.io/en/developers/kafka/ - kind: webhooks status: published generally_available: true direction: outbound note: >- Not a general-purpose subscribable webhook system. Alerts push to caller-supplied destinations on four channels, one of which is a genuine HTTP webhook. There is no event catalog, no signature/HMAC verification, no delivery-retry policy and no replay endpoint documented. configured_by: operations: [post_alert_threshold, post_alert_discrete, post_alert_throughput, enable_alert, disable_alert] schema: '#/components/schemas/AlertNotification' channels: - name: ms_teams kind: http-webhook field: webhook_urls type: array of string detail: Arbitrary caller-supplied Microsoft Teams incoming-webhook URLs. This is the only channel that delivers to an HTTP endpoint the customer controls. - name: telegram kind: chat field: chat_ids type: array of string - name: email kind: email field: recipients type: array of string - name: dashboard kind: in-app field: enabled type: boolean event_types: - alert_threshold - a datapoint crosses an info/critical threshold, with hysteresis (threshold_crit_reset) and a dead-band (threshold_dead) - alert_discrete - a datapoint takes a discrete state - alert_throughput - a datapoint stops delivering data alert_fields: [level, delay, period, repeat, negate, status] gaps: - No AsyncAPI, CloudEvents or event-schema registry published by aedifion. - No general webhook subscription API - outbound push exists only as alert notification channels. - No webhook signature or HMAC verification documented for the MS Teams channel. - No delivery guarantees, retry policy or dead-letter surface documented for notifications. - Kafka bootstrap servers are not published, so the interface is not usable from public docs.