Microsoft Graph HTTP Status Codes in Power Automate
Diesen Beitrag auf Deutsch lesen
Use Graph status codes to diagnose authentication, permissions and throttling issues, while preventing duplicate records from unsafe Power Automate retries.
TL;DR
Power Automate flows calling Microsoft Graph should distinguish 401 authentication failures from 403 permission failures, wait using retry-after after 429 throttling, and protect non-idempotent POST or PATCH retries with idempotency keys or error handling. OAuth 2.0 short-lived bearer tokens reduce exposure compared with static API keys.
Original on M365 FM. Read the original · suggested by Mirko Peters
This is our own summary, not a republication or full translation.
Governance takeaway
- Makers: Treat GET, HEAD, PUT, and DELETE as idempotent, but protect POST and PATCH retries with idempotency keys or checks because failures can create duplicate emails, rows, or orders.
- Admins/CoE: Diagnose 401 through sign-in or token validity, 403 through Entra ID permissions, and 429 through retry-after handling so flows recover without repeated requests, unnecessary password resets, or throttling blocks.
Frequently asked questions
How should Power Automate handle a Microsoft Graph 429 response?
The flow should read the retry-after header and wait before sending the request again. Immediate repeated requests can worsen throttling.
What is the difference between Microsoft Graph 401 and 403 errors?
A 401 means authentication failed or the token is invalid or expired. A 403 means the identity lacks required API permissions.
How can Power Automate prevent duplicate records after Microsoft Graph POST retries?
Use idempotency keys or error handling for POST retries. Repeated non-idempotent requests can create duplicate emails, database rows, or orders.