/team/log/get_events Not giving data past 2019

[Jacob_F 2023]

Calling /team/log/get_events doesn't give me any data for my client past 2019, tried with multiple categories, no categories, and limiting by time. Using OAuth.

[Greg-DB]

Thanks for the report! I just tried this functionality myself, and I was able to retrieve events from after 2019 using the /2/team_log/get_events[/continue] endpoints, so we'll need to look into this more specifically for you.

So that we can reproduce and investigate the issue you're seeing, please reply with:

• the name and version number of the Dropbox SDK/library you are using, if any
• the steps to reproduce the issue, including relevant code snippet(s), but don't include any access or refresh token(s)
• the text of any error or unexpected output, but please redact any private information

Thanks in advance!

[Biswamber_Khandei]

To address the task of retrieving the last access date of individual users in Dropbox, particularly when Single Sign-On (SSO) is enabled with Azure AD, please find the following clarifications and concerns:

1. We are utilizing the following API endpoint to fetch login-related events for users with "Category": "logins" and "sso," using an OAuth2 Access Token:

API Endpoint: POST https://api.dropboxapi.com/2/team_log/get_events 

Request Body:
{
"limit": 1000,
"category": "logins"
}
or
{
"limit": 1000,
"category": "sso"
}

This API response provides us with the user's Last Access showing as nobody has logged in since 2018.

2. When attempting to retrieve events without specifying a category, the API returns events from various categories, but it seems to exclude events from the current year or month. To specify a start date, we included the "time" parameter in the request body as follows: "time": {"start_time": "2023-01-01T00:00:00Z"}

However, it appears that this does not yield events starting from January 1, 2023. Surprisingly, when we adjusted the start date to "2019-01-01T00:00:00Z," it did provide a response. But upon changing the start date to "2019-02-01T00:00:00Z," it no longer returned any results.

3. Another concern we encountered is that the API does not provide a response that matches the specified limit of "100."

Given these challenges, we seek guidance on possible methods to obtain the last access information of individual users, even in scenarios where Dropbox has SSO enabled. We would greatly appreciate the opportunity to schedule a web call to demonstrate the issues we are facing and explore potential solutions.

Please let us know your availability for a web call. Your assistance would be highly valuable in addressing these concerns effectively.

[Greg-DB]

Thanks for following up with this additional information. We do not currently provide API support over web calls, but we can continue helping here.

Looking at the information you provided, I see you're calling /2/team_log/get_events, but you didn't mention or show how you're checking the result and calling back to /2/team_log/get_events/continue if/when needed. Please note that the /2/team_log/get_events[/continue] interface is paginated, and you're not guaranteed to get all results back in one call, so you'll need to make sure you have code implemented to be able to check the returned 'has_more' value to determine if/when to call back to /2/team_log/get_events/continue to retrieve the next page of results, and so on. Please refer to the linked documentation for more information on how to use that. If you do have that implemented to paginate through all pages while 'has_more' is true but still aren't receiving the expected results, please share the relevant code and output so we can look into it.

Also, note that the 'limit' parameter is a way for the app to request a maximum number of events to return per page, but the server may still return less than that number on any given page (or even no events, in some cases).

[Biswamber_Khandei]

Based on your input:
We are calling /2/team_log/get_events/continue by passing the Access Token in the Authorization and the "cursor" in the body only when there is "has_more": true in the /2/team_log/get_events API.

The API's response does not seem to adhere to the specified "limit" parameter. For instance, when a "limit" of "5" is passed, the API consistently returns only one data entry, even though there is additional data on subsequent pages, indicated by the "has_more" field being set to "true." Subsequently, when the /2/team_log/get_events/continue API is called, it provides 5 or 6 data entries, possibly even more.

[Greg-DB]

Yes, while the app can request a maximum number of events to return per page, in some cases the server may return fewer than that number. That means that when you send a limit of 5, it is possible that the API will return one or even zero events on any given page. This will vary depending on a number of factors on the backend.

Similarly, though it's working in my testing and I don't have specific information/documentation on this but while the limit is meant as a maximum, due to how things are batched on the backend, from your description it's possible you might be seeing somewhat more than that in some cases. That being the case, I recommend making sure your app doesn't strictly enforce that and doesn't crash if it receives more than the requested number of events per page.

[Biswamber_Khandei]

Based on your inquiry and the information provided, will the "get_events" endpoint return details or a response related to the "logins" category even when a user logs in using Single Sign-On (SSO)?

Another concern arises if a user logged into Dropbox on September 1, 2023, and has not logged out since that day, but continues to access their account daily due to having selected the "Remember me" option. In this scenario, what date will be included in the response?

[Greg-DB]

Yes, the "logins" events apply to logging in using SSO as well.

The "timestamp" on a TeamEvent is the date/time the event itself took place. So for a login, it's the time the user logged in, regardless of how long they stay logged in after that.

[Biswamber_Khandei]

Thank you for your prompt response. Let's consider a scenario where I log in to Dropbox today using Single Sign-On (SSO) and remain logged in for over three days. During this time, I use the Dropbox application daily and perform various activities. I do not manually click the "Login" or "Sign in using Microsoft" button daily because I have selected the "Remember me" option. In this situation, if I were to make an API request after three days, would it return the current timestamp(3rd or 4th day's timestamp) or today's timestamp(when I last time logged in using SSO)?

Additionally, could you please clarify the automatic sign-out time period when logging in with SSO?

[Greg-DB]

The timestamp for the event would be the original timestamp for when the event itself took place, that is, when the user logged in, not when the API call to get_events was made.

I can only provide help regarding the API itself. For help regarding the properties of the sign-in functionality itself please refer to the help center or contact support.