Create Application Usage Report from API

The Admin Application Usage Report (https://{yourOktaDomain} provides a condensed user application access report by application (or across all applications) within an available time period. The report displays the following attributes:

  • Person
  • Login (fixed at user creation)
  • Application Username
  • Instance Name
  • Login Date
  • Login Date_ISO8601

Is there a way to produce this exact Application Usage Report directly from the API?

When I run a report against the log API (/api/v1/logs) using filter=eventType eq “user.authentication.sso” and outcome.result eq “SUCCESS” - the Login from the the Application Usage Report does not match the SysLog actor.alternateId or the target.alternativeId (AppUser) when a user has changed their email / username in their settings. The Application Usage Report retains the original Username / Login even for time periods occurring before the email / username change.

Hi there. As far as I know there is no way to make this happen purely with an API call. You would need to take the response from /logs, iterate through it and collate this data based off the actor id, which is the immutable unique id given to each user by Okta.


Thanks for the reply. Against which API endpoint would I send the UID to iteratively retrieve the immutable actor ids (Login)? When I tried the Get User with ID method after a profile email change, the profile login, profile email, and credentials emails all show the newly changed email and NOT the original immutable email.

Sorry, I meant you would need to iterate and handle the logic locally. So my thought was (in psuedo-code):

users = {}

for user in response:
  if in users:
    users[].logins += 1
    users[] = {
        logins: 0,

But of course this thought was off the cuff - hopefully it actually solves what you’re looking to accomplish!


Thanks for the reply. My issue is that after a user changes their email, the original email (original@email"."com in the example below) no longer appear in the SysLog file. The original email is also NOT available in the /users API response. How does the Application Usage report retain and display the original email? Where can this original email data be pulled?

Person Login Application username Instance name Login Date Login Date_ISO8601
Joe Smith original@email".“com NEW@email”.“com Application 2 10/26/21 12:11:51 PM PDT 2021-10-26T19:11:51.000Z
Joe Smith original@email”.“com NEW@email”.“com Application 1 10/26/21 12:11:50 PM PDT 2021-10-26T19:11:50.000Z
**** usename / email changed from original@email”.“com to new@email”.“com ****
Joe Smith original@email”.“com original@email”.“com Application 2 10/26/21 12:02:49 PM PDT 2021-10-26T19:02:49.000Z
Joe Smith original@email”.“com original@email”."com Application 1 10/26/21 12:02:40 PM PDT 2021-10-26T19:02:40.000Z

SAMPLE TRUNCATED LOG REPORT (eventType eq “user.authentication.sso” and outcome.result eq “SUCCESS”):
actor.display_name actor.alternate_id target1.alternate_id target0.alternate_id timestamp
Joe Smith NEW@email".“com NEW@email”.“com Application 2 2021-10-26T19:11:51.963Z
Joe Smith NEW@email”.“com NEW@email”.“com Application 1 2021-10-26T19:11:50.012Z
**** usename / email changed from original@email”.“com to new@email”.“com ****
Joe Smith original@email”.“com original@email”.“com Application 2 2021-10-26T19:02:49.507Z
Joe Smith original@email”.“com original@email”."com Application 1 2021-10-26T19:02:40.929Z

GET /api/v1/users/00*****************
Status: 200 success
“id”: “00*****************”,
“status”: “ACTIVE”,
“created”: “2020-04-23T18:26:03.000Z”,
“activated”: “2020-04-23T18:28:47.000Z”,
“statusChanged”: “2020-05-22T17:26:39.000Z”,
“lastLogin”: “2021-10-26T21:31:41.000Z”,
“lastUpdated”: “2021-10-26T21:32:12.000Z”,
“passwordChanged”: “2021-09-15T16:58:26.000Z”,
“type”: {
“id”: “ot00***************”
“profile”: {
“firstName”: “Joe”,
“lastName”: “Smith”,
“mobilePhone”: “555551212”,
“secondEmail”: “”,
“login”: “”,
“email”: “
“credentials”: {
“password”: {},
“emails”: [
“value”: “”,
“status”: “VERIFIED”,
“type”: “PRIMARY”
“value”: “”,
“status”: “VERIFIED”,
“type”: “SECONDARY”
“provider”: {
“type”: “OKTA”,
“name”: “OKTA”