Microsoft Graph Approvals API — Was funktioniert, was nicht, und warum das wichtig ist

Wir wollten eigentlich nur eines: Teams-Genehmigungen programmatisch erstellen und verwalten. Aus einer eigenen App heraus, ohne Power Automate, ohne Umwege. Die Microsoft Graph Approvals API klang nach genau dem richtigen Werkzeug.

Spoiler: Die API ist Beta — und das merkt man. Deutlich.

Was folgt, ist ein ehrlicher Erfahrungsbericht. Damit ihr nicht die gleichen Stunden verbrennt wie wir.

Was die Approvals API verspricht

Die Approvals API unter /beta/solutions/approval/approvalItems bietet auf dem Papier alles, was man braucht:

• Genehmigungen erstellen — programmatisch, mit Titel, Genehmigern und Antwortoptionen
• Genehmigungen lesen — Status abfragen, Ergebnisse auswerten
• Echtzeit-Updates per Webhook — Subscriptions auf Änderungen, damit man nicht pollen muss

Dazu zwei Permission-Modelle:

Klingt sauber. Ist es aber nicht.

Was tatsächlich funktioniert

Genehmigungen erstellen (Delegated)

Das Erstellen von Approvals funktioniert — allerdings nur mit Delegated Permissions und mit einer Besonderheit: Die API antwortet nicht mit dem fertigen Objekt, sondern mit 202 Accepted und einer Operation-URL zum Pollen.

Request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

POST https://graph.microsoft.com/beta/solutions/approval/approvalItems
Authorization: Bearer {delegated-token}
Content-Type: application/json

{
  "title": "Urlaubsantrag genehmigen",
  "description": "Max Mustermann beantragt 5 Tage Urlaub",
  "approvers": [
    {
      "user": {
        "id": "approver-user-id",
        "displayName": "Erika Musterfrau"
      }
    }
  ],
  "responseOptions": [
    { "response": "Approve", "displayValue": "Genehmigen" },
    { "response": "Reject", "displayValue": "Ablehnen" }
  ]
}

Response — nicht das Objekt, sondern ein Redirect:

1
2

HTTP/1.1 202 Accepted
Location: https://graph.microsoft.com/beta/solutions/approval/operations/{operation-id}

Dann heißt es: Pollen, bis status auf succeeded steht. Die echte Approval-ID steckt im Feld resourceLocation der Operation-Response.

1
2
3
4
5

{
  "id": "{operation-id}",
  "status": "succeeded",
  "resourceLocation": "https://graph.microsoft.com/beta/solutions/approval/approvalItems/{approval-id}"
}

Ungewöhnlich, aber funktional. Haken dran.

Genehmigungen lesen (Delegated)

Mit Delegated Token klappt auch das Lesen:

1
2

GET https://graph.microsoft.com/beta/solutions/approval/approvalItems
Authorization: Bearer {delegated-token}

Funktioniert. Keine Überraschungen.

Was nicht funktioniert

Und hier wird es interessant.

Problem 1: Approvals lesen mit App-Permissions → 401

Die Permission ApprovalSolution.ReadWrite.All beschreibt sich selbst als:

“Read all approvals and manage approval subscriptions”

Man erwartet also: App-Token holen, Approvals lesen, fertig. Wir hatten die Permission im Azure AD konfiguriert, Admin Consent erteilt — alles nach Lehrbuch.

Request:

1
2

GET https://graph.microsoft.com/beta/solutions/approval/approvalItems
Authorization: Bearer {app-token}

Response:

1
2
3
4
5
6
7
8

HTTP/1.1 401 Unauthorized

{
  "error": {
    "code": "Unauthorized",
    "message": "Failed to authorize the client, required scope(s) or role(s) not present."
  }
}

Das war verwirrend. Token war gültig, Permission war granted. Was war los?

Die Auflösung findet sich nicht in der Permission-Beschreibung, sondern in der API-Referenz der einzelnen Endpoints. Dort steht bei List und Get approvalItems:

Application permissions: Not supported.

Die Permission-Beschreibung sagt “Read all approvals”. Die Endpoint-Dokumentation sagt “Not supported”. Das widerspricht sich direkt.

Von Microsoft bestätigt: Der Support hat dieses Verhalten reproduziert und als Dokumentations-Inkonsistenz bestätigt. Die Endpoint-Dokumentation ist maßgeblich — App-only Lesen wird aktuell nicht unterstützt. Eine Korrektur der Permission-Beschreibung wurde an das Engineering-Team weitergeleitet.

Problem 2: Webhook-Notifications werden nie zugestellt

Das war der frustrierendste Teil. Subscriptions auf Approval-Änderungen erstellen? Klappt einwandfrei:

Request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

POST https://graph.microsoft.com/beta/subscriptions
Authorization: Bearer {app-token}
Content-Type: application/json

{
  "changeType": "created,updated",
  "notificationUrl": "https://our-app.example.com/webhook",
  "resource": "solutions/approval/approvalItems",
  "expirationDateTime": "2026-03-06T00:00:00Z",
  "clientState": "our-secret-state"
}

Response — alles sieht gut aus:

1
2
3
4
5
6
7
8
9

HTTP/1.1 201 Created

{
  "id": "{subscription-id}",
  "resource": "solutions/approval/approvalItems",
  "changeType": "created,updated",
  "notificationUrl": "https://our-app.example.com/webhook",
  "expirationDateTime": "2026-03-06T00:00:00Z"
}

Der Validation-Handshake funktioniert: Microsoft sendet einen validationToken, unser Endpoint antwortet korrekt mit 200 OK und dem Token im Body. Subscription wird erstellt und ist auch per GET abrufbar.

Und dann: Stille.

Wir erstellen Approvals in Teams. Wir genehmigen sie. Wir lehnen ab. Keine einzige Notification kommt an.

Unser Endpoint war erreichbar — das hat der Validation-Request ja bewiesen. Wir haben Logs, wir haben getestet. Nichts.

Eine Suche in der Microsoft Q&A Community zeigt: Wir sind nicht die einzigen. Andere Entwickler berichten exakt das gleiche Verhalten — erfolgreiche Validation, aber keine Change Notifications.

Von Microsoft bestätigt: Der Support kann das Problem reproduzieren. Wörtlich: “The subscription creation and validation handshake succeed, but no events arrive when approvals are created/updated in Teams.” Es handelt sich um eine aktuelle Produktlimitation des Beta-Endpoints.

Problem 3: v1.0 Endpoint existiert nicht

Die Change Notifications Übersicht listet solutions/approval/approvalItems als unterstützte Resource — ohne Asterisk, was v1.0-Support impliziert.

Request:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

POST https://graph.microsoft.com/v1.0/subscriptions
Authorization: Bearer {app-token}
Content-Type: application/json

{
  "resource": "solutions/approval/approvalItems",
  "changeType": "created,updated",
  "notificationUrl": "https://our-app.example.com/webhook",
  "expirationDateTime": "2026-03-06T00:00:00Z"
}

Response:

1
2
3
4
5
6
7
8

HTTP/1.1 400 Bad Request

{
  "error": {
    "code": "BadRequest",
    "message": "Resource not found for the segment 'approval'."
  }
}

Approvals existieren ausschließlich unter /beta. Die Dokumentation wurde inzwischen zur Korrektur weitergeleitet.

Was das für die Praxis bedeutet

Fassen wir zusammen. Stand März 2026:

Das Ergebnis: Ohne funktionierende Webhooks und ohne App-only Lesezugriff ist die Approvals API für Automatisierungs-Szenarien aktuell kaum nutzbar.

Was bleibt als Workaround?

• Polling mit Delegated Token — Funktioniert, aber erfordert gespeicherte User-Tokens mit Refresh-Token-Handling und skaliert schlecht
• Power Automate — Microsofts eigener Weg, der funktioniert, aber den Sinn einer eigenen API-Integration konterkariert
• Warten — Die API ist Beta, und der Support hat eine Weiterleitung an das Engineering-Team bestätigt

Fazit

Die Microsoft Graph Approvals API hat Potenzial. Die Idee, Genehmigungsprozesse per API zu steuern, ist richtig und wichtig. Aber Stand heute fehlen grundlegende Bausteine:

1. Drei Probleme — alle von Microsoft Support bestätigt
2. Dokumentation widerspricht sich selbst
3. Der zentrale Use Case (Echtzeit-Updates per Webhook) funktioniert schlicht nicht

Unsere Empfehlung: Behaltet die API im Auge, aber plant aktuell nicht damit für Produktions-Szenarien. Beobachtet das Graph Changelog und den Q&A Thread für Updates.

Wir bleiben dran und berichten, sobald sich etwas tut.

Habt ihr ähnliche Erfahrungen mit der Approvals API gemacht? Oder nutzt ihr einen anderen Weg, um Genehmigungen in Teams zu automatisieren? Schreibt es in die Kommentare oder meldet euch bei uns auf LinkedIn.