API Call User Last_Request

[Chris_Boothman]

Is there any API call that can be used to pull in the last_request value that is displayed on the login information section of the user profile?

We currently run the following API /api/v1/accounts/1/users?per_page=300&include[]=last_login which works great to pull in the Last Login value which we move over to a CRM student success platform, but we believe the Last Request value would be a more accurate representation for each user for those that have the same login session.

Any assistance would be greatly appreciated.

Thanks,

Chris

[James · Accepted solution]

@Chris_Boothman 

The last_request_at property is part of the pseudonyms record. Support for that record through the API is extremely limited -- only as part of another API, not having a public API of its own. Unfortunately, the last_request_at field is not exposed through the REST API.

You could use the Last User Access to get it for all of your students. It's not up to the minute accurate, but if you're only updating your CRM once a week or once a day, you could automate generating and fetching that report and use it to get your data. Note that it's not up-to-the minute, but within 10 minutes. According to the help, "Please note, Last Access At is updated once every 10 minutes. That is our current threshold to determine activity for any given user session." But it is the same information you're asking about.

The last_request_at is available through the Canvas Data 2 pseudonyms table where the field is described as "Timestamp of when the user last logged in with this pseudonym." Compare that with last_login_at, which is "Timestamp of last time a user logged in with this pseudonym." Maybe you understand the difference between those two statements, but I am not seeing it. That said, they are obviously different, so it's probably the description that is off.

There are a few ways that you can use the API to get something similar, but they are going to take a lot of requests.

• There is a last_activity_at property but it resides under at the course level, not user level. Someone might have been active in their psychology course while not doing anything in their mathematics course and this allows you to distinguish where they are truly active. This is found under the enrollments API, so you would need to make a request from each course the student is enrolled in and then curate the information to figure out when the last time they did anything was.
• You can list the user page views (found under the Users API) and specify per_page=1. The results come with the most recent (newest) first, so the per_page=1 means you only have to get the most recent request. This is tied to the user and not the pseudonym that they logged in under.

Both of those approaches require a lot of iterations: once per course for the enrollments with possible pagination if you have more than 100 students or once per user for the page views but no additional pagination. Normally, the once per course route is faster, but the enrollments API is an expensive one (x-rate-limit-remaining wise) and uses bookmarks for pagination as opposed to numbered pages.

When I was collecting student data for an early-alert system, I always relied on the last_activity_at and total_activity_time from the enrollment record and never the last login information. If they are using the mobile app, the last login may be ancient compared to when they are doing activity. I also recorded those two values daily so that I could track it over time to see when the students were actually doing work. I had too many students using the mobile app that were showing last_activity_at in a course they hadn't been in for two years -- but Canvas was hitting that course because they still had access to it. There are little things to watch out for no matter what approach you take.

On a different note, have you checked your per_page=300 to make sure you're getting 300 results? Most are capped at 100 items and you'll have to use pagination to get more. I've seen some people on here recommend arbitrarily large values, but it usually is a result of someone perpetuating something they didn't really understand.

[Chris_Boothman]

@James Thanks so much, this is extremely helpful and I appreciate the detailed information to help provide better clarification on this. After I submitted this post, I realized for our specific current use case, the "Last User Access" in the delivered report would likely be sufficient for our needs. We are going to move forward with pulling that on a daily basis to populate in our CRM. At some point, I think targeting the specific activity date on each course would be helpful, so looking at the course level would be the route we will then take.

Yes, we are using pagination on our API call to actually get the last login currently for all users - the version I included above I realized quickly wasn't actually pulling 300, rather it was just an arbitrary number beyond the 100.

Appreciate the response on this.