How to access Defender for Cloud Apps data and store it for long-term Power BI analysis?

Hi  v-achippa 

Thanks a lot for the detailed pointers.

We tried both pagination patterns you suggested on /api/v1/discovery/app_users, but we’re still stuck:

What we did

We have 2 streamIds. One returns “no data”. The other returns total: 101 and "hasNext": false on the very first call.

Request #1 (first page):

POST /api/v1/discovery/app_users

{

"filters": {},

"streamId": "<streamId>",

"appId": 11394,

"timeframe": 90,

"sortField": "trafficTotalBytes",

"sortDirection": "desc",

"limit": 100

}

Response (excerpt):

 {

"results": [ ... 101 items ... ],

"total": 101,

"hasNext": false

}

So there’s no nextQueryFilters returned, and hasNext is already false on page 1.

What we tried next

1.Putting only the nextQueryFilters keys inside filters (as recommended).

When we attempt a second call with:

{

"filters": { "skip": 101, "page": 2 },

"streamId": "<streamId>",

"appId": 11394,

"timeframe": 90,

"sortField": "trafficTotalBytes",

"sortDirection": "desc",

"limit": 100

}

…we get:

"detail": "Invalid filter params were sent to API: {'skip': 101, 'page': 2}"

2.Nesting nextQueryFilters inside filters (alternative shape):

{

"filters": {

"nextQueryFilters": { "skip": 101, "page": 2 }

},

"streamId": "<streamId>",

"appId": 11394,

"timeframe": 90,

"sortField": "trafficTotalBytes",

"sortDirection": "desc",

"limit": 100

}

This also fails with a similar “Invalid filter params” error.

 Because of the above, the REST path isn’t letting us advance beyond the first 101 users.

 Questions on REST

 Could you confirm the exact expected JSON shape for filters in app_users pagination?

– Should filters contain only the returned nextQueryFilters keys (e.g., skip, page), without any other fields?

– Or should we nest them as { "filters": { "nextQueryFilters": { ... } } }?

– Is there a chance page isn’t supported in our tenant and we must send only skip?

Given our first-page response already has "hasNext": false, is it expected that some apps/streams truly have only 101 users? (If so, that would explain things; just want to double-check.)

Graph API path (works) & follow-ups

In Graph Explorer we can list users for the app via (example):

GET /beta/security/dataDiscovery/cloudAppDiscovery/uploadedStreams/{streamId}/aggregatedAppsDetails(period=duration'P90D')/{appId}/users?$skip=300

This returns the next page of users correctly.

What we still need is guidance on other fields beyond the user list:

Which Graph endpoints/properties expose the aggregated metrics we see in MCAS (e.g., trafficTotalBytes, trafficUploadedBytes, lastSeen, etc.) per app and/or per user?

– Is it via the {appId} resource of aggregatedAppsDetails(...) with $select?

– Is there a way to get per-user traffic totals via Graph, or only app-level aggregates?

Any recommendations on pagination best practices here: should we prefer $top + @odata.nextLink over $skip, or is $skip the intended approach for these endpoints?

Which permissions/scopes do you recommend for production (delegated/app)? (e.g., which exact Security/Cloud App Discovery scopes are required.)

Finally, is there a v1.0 equivalent for these endpoints, or is /beta currently the only available surface?

Thanks again for your help—any sample queries/snippets showing how to pull users + their traffic metrics for a given {streamId, appId, period} would be greatly appreciated.