Microsoft Purview API Export Permissions Clarification

Question

Microsoft Purview API Export Permissions Clarification

Michael Henehan 0

I'm trying to download an export from Microsoft Purview using the API. I'm using delegated auth. When I download the export with a user with eDiscovery Manager permissions, I get a 401 error. When I try the same download with a user with eDiscovery Admin permissions, it succeeds.

What permissions am I missing? eDiscovery Admin is too permissive for my use case, but, from the documentation, eDiscovery Manager should be enough. Additional information:

I've added the eDiscovery Manager to the case and the user with eDiscovery Manager permissions. I still get the 401.
Oddly when I try to download the export from the UI, it works. Then, when I try and download that same export from the API, it succeeds. I'm not sure why this would be the case, but I'd like to be able to be able to automate export downloads without having to go into the UI every time I need to download an export.
This is in a GCC medium tenant. Are there more permissions required in that tenant?
I've also tried creating a role with all possible permissions, and this lets me download the export, but I'd like to know specifically what is required beyond eDiscovery Manager.

Thanks for the help!

Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-04-30T22:30:49.84+00:00
Hi @Michael Henehan

While the eDiscovery Manager role is sufficient to create searches and initiate exports (which is why the UI flow works as expected), the download of export artifacts is validated more strictly when accessed via API. In some scenarios, this role may not have sufficient access to retrieve the export through the API, which can result in the 401 error you’re seeing.

Additionally, export downloads are handled through a separate Microsoft Purview eDiscovery API, which requires dedicated authentication and access to generated download metadata (exportFileMetadata). This introduces additional validation beyond standard Graph permissions.

When a download is initiated (for example, via the UI), the service may generate or initialize a downloadable artifact or link for that export. Once this step is completed, subsequent API requests are able to access the export successfully.

This also aligns with how pre-authorized download links can be used in export settings. These links act as temporary access tokens for export packages and can allow access without repeated authentication, which may contribute to the difference in behavior between UI and API flows.

To reduce recurrence, you may consider:

Using eDiscovery Administrator (or a custom role with equivalent export permissions) for automation scenarios

Ensuring the export job is fully completed before attempting API-based downloads

Could you please confirm whether pre-authorized download links are enabled in your environment? If not, and if it aligns with your security requirements, enabling this setting may help improve consistency for export downloads.

Reference: https://learn.microsoft.com/en-us/purview/edisc-settings-export

Please let us know if you have any questions or concerns.
Michael Henehan 0 Reputation points

2026-05-01T14:28:12.15+00:00

Pre-authorized download links are not enabled for my environment, but unfortunately I can not enable them due to security requirements.
Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-05-01T21:52:26.4433333+00:00

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.
Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-05-04T06:03:20.08+00:00

Hi @Michael Henehan

We haven’t received a response. Please let us know if you need any additional information or assistance from my side.

1 answer

Your answer

Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-04-30T22:30:49.84+00:00

Hi @Michael Henehan

While the eDiscovery Manager role is sufficient to create searches and initiate exports (which is why the UI flow works as expected), the download of export artifacts is validated more strictly when accessed via API. In some scenarios, this role may not have sufficient access to retrieve the export through the API, which can result in the 401 error you’re seeing.

Additionally, export downloads are handled through a separate Microsoft Purview eDiscovery API, which requires dedicated authentication and access to generated download metadata (exportFileMetadata). This introduces additional validation beyond standard Graph permissions.

When a download is initiated (for example, via the UI), the service may generate or initialize a downloadable artifact or link for that export. Once this step is completed, subsequent API requests are able to access the export successfully.

This also aligns with how pre-authorized download links can be used in export settings. These links act as temporary access tokens for export packages and can allow access without repeated authentication, which may contribute to the difference in behavior between UI and API flows.

To reduce recurrence, you may consider:

Using eDiscovery Administrator (or a custom role with equivalent export permissions) for automation scenarios

Ensuring the export job is fully completed before attempting API-based downloads

Could you please confirm whether pre-authorized download links are enabled in your environment? If not, and if it aligns with your security requirements, enabling this setting may help improve consistency for export downloads.

Reference: https://learn.microsoft.com/en-us/purview/edisc-settings-export

Please let us know if you have any questions or concerns.
Michael Henehan 0 Reputation points

2026-05-01T14:28:12.15+00:00

Pre-authorized download links are not enabled for my environment, but unfortunately I can not enable them due to security requirements.
Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-05-01T21:52:26.4433333+00:00

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.
Manoj Kumar Boyini 13,930 Reputation points Microsoft External Staff Moderator

2026-05-04T06:03:20.08+00:00

Hi @Michael Henehan

We haven’t received a response. Please let us know if you need any additional information or assistance from my side.

Answer 1

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!

Michael Henehan 0 Reputation points

2026-04-30T22:02:34.3233333+00:00

The token does have eDiscovery.Download.Read.

I have to use delegated auth for this use case.

This is possible, but when I elevate the user's roles, it seems to get propagated fairly quickly and I'm able to download the export. So, I'm skeptical this is the case.

Share via

Microsoft Purview API Export Permissions Clarification

1 answer

How to fix it for Automation:

Your answer