Microsoft Purview API Export Permissions Clarification

Hi @Michael Henehan

The most relevant point is that export download is handled through a separate flow using the exportFileMetaData.downloadUrl, which involves additional authentication and access validation beyond standard Graph operations. This is directly relevant to the 401 you are seeing when calling the API.

It also aligns with the RBAC model where Export is a separate role, and even though an eDiscovery Manager can create and manage exports, it doesn’t always guarantee access to download export artifacts via API. In contrast, eDiscovery Administrator has broader access across cases and export operations, which explains why it works consistently.

For your case, the practical takeaway is to verify that the user is a member of the case and has the required Export and Preview roles, and validate this using Diag:edisRBACdiag. Also ensure the export job is fully completed before attempting API download.

References:
https://learn.microsoft.com/en-us/purview/edisc-permissions
https://learn.microsoft.com/en-us/purview/edisc-ref-api-guide

Hope this helps. Please let us know if you have any questions or concerns.

This is a known architectural quirk with how Purview issues the actual download link (which usually points to an proxyservice.ediscovery endpoint).

• eDiscovery Admins have tenant-wide global access, so the proxy server validates their token instantly.
• eDiscovery Managers only have case-level access. When you make an API call, the proxy server doesn't always automatically evaluate this case-level membership. However, when you click download in the UI, the web portal forces a Just-In-Time (JIT) sync that validates your case membership and caches a token for the proxy. Once the UI creates this cache, your API call piggybacks off it and succeeds.

How to fix it for Automation:

1. Add the Hidden "Download" Scope (If you must use Delegated Auth) If you are strictly using delegated authentication, your app token is likely missing the specific download scope required by the proxy server.

You must grant your App Registration the eDiscovery.Download.Read permission.

Note: You won't find this in the standard Graph API permissions. You must request it from the multi-tenant MicrosoftPurviewEDiscovery app (App ID: b26e684c-5068-4120-a679-64a5d2c909d9).

• When your API calls the proxy download URL, ensure your GET request headers include: X-AllowWithAADToken: true.

2. Switch to Application (App-Only) Authentication (Recommended for Automation). Because delegated auth relies heavily on these UI/User token syncs, the best practice for automating export downloads is to use a Service Principal (App Registration) with Application permissions (eDiscovery.Read.All or eDiscovery.ReadWrite.All). By adding the Service Principal directly to the case, you bypass the JIT user-sync requirement entirely.

3. Account for GCC Sync Delays. Since you are in a GCC Medium tenant, Azure AD to Purview role synchronizations (like adding a Manager to a case) can take significantly longer to propagate to the API proxy endpoints than the UI. If you add a Manager to a case, the API may throw a 401 for up to 24 hours until the backend syncs, unless you force it by touching the UI.

Key Takeaway: If you want to stop touching the UI, try adding the eDiscovery.Download.Read permission to your app and the X-AllowWithAADToken header to your API call, or switch to App-Only authentication!