Purview Data Map Atlas /entity/* endpoints return 500 from non-Azure caller egress; identical calls succeed from Azure Cloud Shell same minute

Question

SUMMARY A Microsoft Purview Data Map Atlas v2 entity GET endpoint (entity/guid, entity/uniqueAttribute, entity/guid minimal) returns HTTP 500 with a generic "Internal server error" body when called from a non-Azure serverless runtime (AWS-hosted egress). Identical calls — same service principal, same token, same URL, same minute — return HTTP 200 from Azure Cloud Shell. The Discovery POST /datamap/api/search/query endpoint returns 200 from both callers. This points to an Azure Front Door / data-plane gateway layer rejecting the request before it reaches the Atlas backend, not an account / auth / asset issue.

RESPONSE-HEADER SIGNATURE On 200 responses (from both callers): both x-ms-request-id and x-ms-correlation-request-id are present and match.

On 500 responses (from the non-Azure caller only):

• ONLY x-ms-correlation-request-id is present.
  • x-ms-request-id is absent.
  • Body is the generic {"error":{"code":"Error","message":"Internal server error"}} — no Atlas-style errorCode (e.g. ATLAS-XXX-YY-ZZZ), no body-level requestId.
  • x-cache: CONFIG_NOCACHE.
  Per Microsoft's own AFD troubleshooting docs (https://learn.microsoft.com/en-us/azure/frontdoor/troubleshoot-issues), this header pattern indicates the error originates inside Azure Front Door, before the request reaches the origin. ENDPOINTS TESTED Failing pattern (consistently 500 from non-Azure caller, 200 from Azure Cloud Shell — same SP, same token, same minute): GET https://{account}.purview.azure.com/datamap/api/atlas/v2/entity/guid/{guid}?ignoreRelationships=false&minExtInfo=false&api-version=2023-09-01 GET https://{account}.purview.azure.com/datamap/api/atlas/v2/entity/uniqueAttribute/type/{typeName}?attr:qualifiedName={qn}&api-version=2023-09-01 GET https://{account}.purview.azure.com/datamap/api/atlas/v2/entity/guid/{guid}?ignoreRelationships=true&minExtInfo=true&api-version=2023-09-01 Working from both callers: POST https://{account}.purview.azure.com/datamap/api/search/query?api-version=2023-09-01 PAIRED CORRELATION IDs (UTC 2026-05-12 ~17:30–18:00, same SP, same tenant, same URL pattern) From Azure Cloud Shell — STATUS 200 (x-ms-request-id matches correlation id): 0c430e90-84be-45e4-a25a-1cd58e47f371 6afda525-beee-411d-9ba0-8b04f347a082 777b9fb1-c2e8-4f93-b7a2-53098566aae5 30d8ede9-dc9c-42d3-808b-c8041feec4bc (search/query) From non-Azure (AWS-hosted) serverless egress — STATUS 500 (no x-ms-request-id), same SP token same minute: e5dd865b-24e0-49fd-bdb5-ad2505983b09 0e03b8ee-8fc9-4d00-ac5c-260198177991 b93e1214-beae-4d1b-8c4d-4cb5fcfd5ffd 5f8176b8-a541-4277-a8a8-f2931d323166 8ad245bb-4639-4fde-9d00-64e055292781 86b34aab-f786-4c7e-aaaa-8871c2e50a12 1245e60f-8dff-4756-9b2a-32d3e7a753e8 3e7dd97c-c81b-4911-9712-b6702a30e707 cccc93c1-f60e-4ff7-bb54-2678da24b9f8 532ed391-839b-409a-a078-fdef0ccb8eb2 OAUTH FLOW Client credentials against login.microsoftonline.com/{tenant}/oauth2/v2.0/token with scope https://purview.azure.net/.default. Token acquisition succeeds (200) from both callers. The Atlas response when the request reaches the backend (200 from Cloud Shell) returns full entity JSON with referredEntities and attributes — confirming the data is fine and the backend serves it correctly when the request gets there. ALREADY RULED OUT

1. Auth: token acquisition works from both callers; same token from the non-Azure caller works on /search/query but fails on /entity/*.
2. RBAC: SP has Data Source Admin + Data Curator + Data Reader; works from Cloud Shell.
3. Per-asset / per-collection: tested 9+ assets across multiple collections and qualifiedName roots — all 500 from non-Azure caller, all 200 from Cloud Shell.
4. Asset corruption: Atlas response from Cloud Shell returns full bodies including referredEntities.
5. URL/query-string formatting: identical from both callers.
6. Rate limiting / concurrency: isolated single requests, minutes apart.
7. No matching Azure status-history entries for the Purview service overlapping our time windows.

WHAT I'M ASKING

1. Has anyone seen Atlas v2 entity GET endpoints intermittently 500 with x-cache: CONFIG_NOCACHE + only x-ms-correlation-request-id (no x-ms-request-id) + generic Internal server error body — specifically when called from non-Azure caller egress, while /search/query from the same caller works fine?
2. Is there a known AFD/WAF behavior that selectively rejects /datamap/api/atlas/v2/entity/* from specific egress IP ranges or TLS/User-Agent fingerprints?
3. Is there a documented difference in AFD POP / origin routing between Atlas CRUD endpoints and Discovery endpoints that could cause one to be healthy while the other isn't?

For Microsoft engineers responding: I can share tenant ID, Purview account name, SP object ID, and full failing/working URL captures privately. Please reply on this thread and I'll send via the private comment feature.

Answer 1

Thanks Scott. We swapped to a standard Chrome User-Agent (Mozilla/5.0 … Chrome/121.0.0.0 Safari/537.36) and re-ran the same three Atlas GETs from the same non-Azure egress (Convex on AWS) against the same asset GUID. Result is unchanged — all three endpoints still return bare HTTP 500 with x-cache: CONFIG_NOCACHE, only x-ms-correlation-request-id (no x-ms-request-id), body {"error":{"code":"Error","message":"Internal server error"}}. So the User-Agent fingerprint alone isn't the trigger.

Fresh correlation IDs from this run if anyone on Microsoft engineering can pull AFD edge logs:

• 69532a2f-818c-42fe-9ae9-17ecfaa6d6da — entity/guid
• af2e5c4b-6144-42c2-802e-87d01078d9e9 — entity/uniqueAttribute
• c72d92bd-7a67-414a-8d6b-00af28060f89 — entity/guid (minimal)

Same three endpoint URLs return HTTP 200 with full payload from Azure Cloud Shell using the same service principal and the same minute. Happy to share tenant ID / Purview account name / SP object ID privately if it helps localize the WAF rule or routing policy.

Answer 2

Hello, even though I'm not official engineer but the header signature missing x-ms-request-id with a generic 500 error frequently points to a Web Application Firewall false positive or strict HTTP validation failure at the gateway, often triggered by how the AWS serverless runtime handles outbound GET requests.

You can use a tool like cURL from inside your AWS environment to explicitly set a standard browser User-Agent, ensure Content-Length is omitted or zero, and completely strip any automated runtime headers.

If standardizing the request signature doesn't bypass the block, you will need to open an Azure support ticket providing those specific x-ms-correlation-request-id values so Microsoft engineering can pull the internal Front Door edge logs to identify the exact WAF rule or routing policy causing the drop.