Eingehende Webhooks in Microsoft Teams werden eingestellt: So posten Sie heute mit Workflows (Power Automate) in einen Kanal

Wer in den letzten Jahren Build-Status, Monitoring-Alarme oder Deployment-Meldungen in einen Teams-Kanal geschoben hat, kennt das Muster: ein Incoming-Webhook-Connector pro Kanal, eine URL als Geheimnis, ein POST mit einer MessageCard. Dieser Weg läuft aus. Microsoft stellt die Office-365-Connectors (heute Microsoft-365-Connectors genannt) in Teams ein, und der klassische Incoming Webhook gehört dazu. Dieser Artikel fasst den verifizierten Stand (Juni 2026) zusammen und zeigt den von Microsoft empfohlenen Ersatz über die App "Workflows" (Power Automate) inklusive lauffähiger Code-Snippets.

Das Problem: Connectors werden eingestellt

Microsoft hat die Einstellung am 3. Juli 2024 angekündigt. Der ursprüngliche Plan sah zwei Wellen vor:

• Wave 1, ab 15. August 2024: Das Anlegen neuer Connectors wird blockiert.
• Wave 2, ab 1. Oktober 2024: Alle Connectors stellen ihren Dienst ein.

Diese Termine wurden mehrfach verschoben. Zwei Punkte sind für den Betrieb heute entscheidend:

• URL-Migration: Bestehende webhook-basierte Connectors (Incoming Webhook und Drittanbieter-Connectors) mussten auf eine neue, sicherere URL umgestellt werden. Die Frist hierfür wurde auf den 31. Januar 2025 verlängert. Polling-Connectors wie RSS sind davon nicht betroffen.
• Endgültige Einstellung: Der finale Rollout ist von Microsoft für den Zeitraum vom 18. Mai 2026 bis 22. Mai 2026 dokumentiert. Nach dem 22. Mai 2026 funktionieren die Office-365-Connectors nicht mehr.

Stand Juni 2026 ist dieser Rollout-Zeitraum damit abgeschlossen. Wer noch Incoming Webhooks im Einsatz hat, sollte die Migration nicht weiter aufschieben. Das Anlegen neuer Connectors über das Connector-Entwicklerportal ist bereits gesperrt.

Microsoft nennt als Ersatz ausdrücklich Power-Automate-Workflows, die App "Workflows" in Teams sowie Microsoft Graph als skalierbaren, flexiblen und sicheren Weg, Daten in Teams hinein- und herauszubefördern.

Der empfohlene Ersatz: die App "Workflows"

Die App "Workflows" basiert auf Microsoft Power Automate und ist direkt in Teams integriert. Für den Anwendungsfall "externer Dienst soll per HTTP POST eine Nachricht in einen Kanal schreiben" gibt es den Trigger "Beim Empfang einer Teams-Webhookanfrage" (englisch: "When a Teams webhook request is received"). Microsoft stellt dafür vorgefertigte Vorlagen bereit. Für Kanäle heißen sie laut Microsoft-Support unter anderem "Send webhook alerts to a channel" sowie die Varianten "... from specific people to a channel" und "... from people in an org to a channel"; in einigen Oberflächen und Dokumentationen taucht die Vorlage auch als "Post to a channel when a webhook request is received" auf.

Wichtige Eigenschaften gegenüber dem alten Connector:

• Der Workflow gehört einem Benutzer (Owner), nicht einem Kanal. Fällt der Owner weg und es ist kein Co-Owner gesetzt, kann der Flow zur Waise werden. Setzen Sie daher in produktiven Szenarien Co-Owner.
• Standardmäßig postet der Workflow als "Flow Bot". Der Workflows-Bot kann in Standard- und Shared Channels posten. Das Posten als Flow Bot in privaten Kanälen ist laut Microsoft noch in Entwicklung.
• Workflows unterstützen Adaptive Cards und das Message-Card-Format; die Button-Darstellung des Message-Card-Formats wird allerdings nicht unterstützt.

Schritt für Schritt: Workflow anlegen und URL abrufen

Der schnellste Weg führt über die Vorlage direkt im Teams-Client:

1. Neben dem gewünschten Kanal auf "Weitere Optionen" klicken und "Workflows" wählen.
2. Eine Webhook-Vorlage auswählen, etwa "Send webhook alerts to a channel".
3. Workflow-Namen anpassen und sich mit dem Konto authentifizieren.
4. "Weiter" wählen, dann Team und Kanal als Ziel festlegen.
5. "Workflow hinzufügen" klicken.
6. Die erzeugte Webhook-URL aus dem Dialog kopieren.

Alternativ legen Sie den Workflow von Grund auf an: in Power Automate "Von leer erstellen", den Trigger "Beim Empfang einer Teams-Webhookanfrage" suchen, den Authentifizierungstyp festlegen (Jeder / Jeder Benutzer in meinem Mandanten / Bestimmte Benutzer), anschließend die Aktion "Karte in Chat oder Kanal posten" ("Post card in chat or channel") hinzufügen und Ziel sowie Pflichtfelder füllen. Die Callback-URL wird beim Speichern des Flows angezeigt und ist später im Power-Automate-Designer erneut abrufbar.

Die erzeugte URL ist eine Power-Automate- bzw. Logic-Apps-Trigger-Callback-URL. Sie zeigt typischerweise auf eine Domain im Stil von https://<region>.logic.azure.com:443/... und trägt Query-Parameter, darunter api-version und eine Signatur sig. Genau diese Signatur autorisiert den Aufruf.

Hinweise zur Absicherung:

• Behandeln Sie die komplette URL als Geheimnis. Wer die URL inklusive sig kennt, kann in den Kanal posten. Legen Sie sie in einen Secret Store (z. B. Azure Key Vault), nicht ins Git-Repository.
• Rotation: Bei Verdacht auf Leak löschen Sie den Workflow bzw. generieren den Trigger neu, damit eine neue sig entsteht. Die alte URL wird dadurch ungültig.
• Zusätzliche Auth: Stellen Sie den Triggertyp nicht auf "Jeder", wenn der Aufrufer einem Mandanten zugeordnet werden kann. Mit "Jeder Benutzer in meinem Mandanten" bzw. "Bestimmte Benutzer" verlangt der Trigger zusätzlich einen Auth-Token im Request-Header.

Das neue Payload-Format: Adaptive Card als Attachment

Der entscheidende Unterschied zum alten Connector: Die Workflows-Vorlage erwartet eine Adaptive Card, eingebettet als message mit einem attachments-Array. Der contentType muss application/vnd.microsoft.card.adaptive sein. Das exakte JSON sieht so aus:

{
  "type": "message",
  "attachments": [
    {
      "contentType": "application/vnd.microsoft.card.adaptive",
      "contentUrl": null,
      "content": {
        "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
        "type": "AdaptiveCard",
        "version": "1.2",
        "body": [
          {
            "type": "TextBlock",
            "text": "Deployment erfolgreich auf prod-01"
          }
        ]
      }
    }
  ]
}

Die Pflichtfelder laut Microsoft-Schema: type ist immer "message", attachments ist ein Array von Kartenobjekten, contentType ist immer "application/vnd.microsoft.card.adaptive", contentUrl ist null und content enthält die Adaptive Card als JSON. Tipp aus der Praxis: Halten Sie die Adaptive-Card-Version konservativ (1.2 bis 1.4); sehr neue Versionen werden in Teams nicht immer korrekt gerendert.

Zum Vergleich das alte Office-365-Connector-Format ("MessageCard"), das mit @type und @context arbeitet:

{
  "@type": "MessageCard",
  "@context": "http://schema.org/extensions",
  "themeColor": "0076D7",
  "summary": "Larry Bryant created a new task",
  "sections": [{ "activityTitle": "Larry Bryant created a new task" }]
}

Bei Adaptive-Card-Karten werden alle nativen Schema-Elemente außer Action.Submit unterstützt. Als Aktionen sind Action.OpenUrl, Action.ShowCard und Action.ToggleVisibility zulässig.

Code-Snippets

Die folgenden Beispiele posten die obige Adaptive-Card-JSON an die Workflow-URL. Ersetzen Sie <WORKFLOW_URL> durch Ihre Callback-URL.

curl

curl -H "Content-Type: application/json" \
     -d @card.json \
     "<WORKFLOW_URL>"

PowerShell

$body = Get-Content -Path .\card.json -Raw
Invoke-RestMethod -Method Post `
                  -ContentType 'application/json' `
                  -Body $body `
                  -Uri '<WORKFLOW_URL>'

C# / .NET (HttpClient)

using System.Net.Http.Json;

var card = new
{
    type = "message",
    attachments = new[]
    {
        new
        {
            contentType = "application/vnd.microsoft.card.adaptive",
            contentUrl = (string?)null,
            content = new
            {
                schema = "http://adaptivecards.io/schemas/adaptive-card.json",
                type = "AdaptiveCard",
                version = "1.2",
                body = new[]
                {
                    new { type = "TextBlock", text = "Deployment erfolgreich auf prod-01" }
                }
            }
        }
    }
};

using var client = new HttpClient();
var response = await client.PostAsJsonAsync("<WORKFLOW_URL>", card);

// Power Automate / Logic Apps quittiert den Trigger mit 202 Accepted
if (response.StatusCode == System.Net.HttpStatusCode.Accepted)
    Console.WriteLine("Angenommen (202).");
else
    Console.WriteLine($"Unerwarteter Status: {(int)response.StatusCode}");

Hinweis: Das $schema-Feld heißt im JSON "$schema". Da $ in C#-Anonymous-Types nicht erlaubt ist, wurde es hier als schema notiert; serialisieren Sie in der Praxis mit einem JsonPropertyName-Attribut oder einem Dictionary, damit der Schlüssel $schema exakt erhalten bleibt.

Migration: von MessageCard zu Adaptive Card

Beim Umstieg sind drei Punkte zentral:

• Format wechseln: Der alte @type/@context-MessageCard-Body funktioniert nicht mehr wie gewohnt mit den Workflows (insbesondere ohne Button-Darstellung). Wandeln Sie Ihre Payloads in das message/attachments-Format mit Adaptive Card um. Der "Beim Empfang einer Teams-Webhookanfrage"-Trigger unterstützt keine actionable messages, entfernen Sie daher bei der Konvertierung die actions/potentialAction-Eigenschaften aus alten Payloads.
• Statuscode prüfen: Der alte Incoming Webhook antwortete bei Erfolg mit einem schlichten 1 im Body. Der Power-Automate-/Logic-Apps-Trigger quittiert die Annahme dagegen asynchron mit HTTP 202 (Accepted). Passen Sie Ihre Erfolgsprüfung entsprechend an: Erwarten Sie 202, nicht 200 und nicht den Body 1. Hinweis: 202 bedeutet "angenommen", nicht zwingend "in den Kanal gepostet"; prüfen Sie bei Problemen zusätzlich, ob die Karte tatsächlich erscheint.
• Rate Limits beachten: Für Connectors gelten Durchsatzgrenzen (max. 4 Anfragen pro Sekunde). Implementieren Sie bei höherem Volumen eine Retry-Logik mit exponentiellem Backoff.

ASCII-Schaubild: alt gegen neu

ALT (eingestellt):

  +------------+      +------------------------+      +------------+
  | App/Skript | ---> |  Incoming Webhook      | -X-> | Teams-     |
  | MessageCard|      |  Connector             |  X   | Kanal      |
  +------------+      +------------------------+      +------------+
                          eingestellt ab 22.05.2026


NEU (empfohlen):

  +------------+      +------------------------+      +------------+
  | App/Skript | ---> |  Power Automate        | ---> | Teams-     |
  | Adapt.Card |      |  Workflow (Flow Bot)   |      | Kanal      |
  +------------+      +------------------------+      +------------+
       HTTP POST              -> 202 Accepted

Praxis-Empfehlung

Inventarisieren Sie zuerst alle bestehenden Incoming-Webhook-Aufrufe (Suche nach office.com/webhook bzw. den alten Connector-URLs in Ihren Repos und Pipelines). Legen Sie pro Kanal einen Workflow über die Vorlage an, vergeben Sie mindestens einen Co-Owner, hinterlegen Sie die neue URL als Secret und stellen Sie Ihre Payloads auf das Adaptive-Card-Format um. Testen Sie gegen den 202-Statuscode statt gegen den alten 1-Body. Wer das früh erledigt, vermeidet stille Ausfälle nach dem finalen Rollout.

Bei Fragen zur Migration oder zur Integration in Ihre .NET-Pipelines erreichen Sie mich unter info@yurtbay.dev.

Quellen (Microsoft)

• Retirement of Office 365 connectors within Microsoft Teams
• Microsoft 365 custom connectors
• Create Incoming Webhooks with Workflows for Microsoft Teams
• Microsoft Teams connector reference
• Create and send messages (webhooks & connectors)
• What are webhooks and connectors