Canvas Roster Integrations?

Nick_Yamagata
Community Participant
‎07-09-2019 02:42 PM

Our university has been working with VitalSource to provide e-books and Day-one access to students through Canvas. Things have been working well, instructors and departments decide if they want their e-textbook available in Canvas, we get a list of these courses from VS and provide them the course IDs in our Canvas environment. A little bit of footwork on both the vendor and myself, but it's usually manageable.

During this semester's setup we were introduced to Rostering Integration, we provide the vendor with a Developer Key and then those pre-semester day-one access emails are no longer necessary. However, we're a bit concerned about the level of access a Dev key might provide as well as the student info that would be passed to the vendor.

Has anyone done any sort Roster Integration with VitalSource? I'm curious if any other Higher Ed Canvas admins have any insight on this sort of setup.  If you're integrating with any 3rd-Party vendors this way, what steps do you take to ensure that the student data is being handled properly?

Lastly, when providing a Developer Key, we are able to do some scope enforcing but they are requiring these endpoints specifically:

I. Accounts
   1. url:GET|/api/v1/accounts/:account_id/courses
II. Courses
   1. url:GET|/api/v1/courses
   2. url:GET|/api/v1/courses/:id
III. Enrollment Terms
   1. url:GET|/api/v1/accounts/:account_id/terms
IV. Enrollments
   1. url:GET|/api/v1/courses/:course_id/enrollments
V. External Tools
   1. url:GET|/api/v1/courses/:course_id/external_tools
   2. url:POST|/api/v1/courses/:course_id/external_tools
   3. url:PUT|/api/v1/courses/:course_id/external_tools/:external_tool_id
   4. url:DELETE|/api/v1/courses/:course_id/external_tools/:external_tool_id

VI. Modules
   1. url:GET|/api/v1/courses/:course_id/modules
   2. url:GET|/api/v1/courses/:course_id/modules/:id
   3. url:POST|/api/v1/courses/:course_id/modules
   4. url:PUT|/api/v1/courses/:course_id/modules/:id
   5. url:DELETE|/api/v1/courses/:course_id/modules/:id
   6. url:GET|/api/v1/courses/:course_id/modules/:module_id/items
   7. url:GET|/api/v1/courses/:course_id/modules/:module_id/items/:id
   8. url:POST|/api/v1/courses/:course_id/modules/:module_id/items
   9. url:PUT|/api/v1/courses/:course_id/modules/:module_id/items/:id
   10. url:DELETE|/api/v1/courses/:course_id/modules/:module_id/items/:id
VII. Users
   1. url:GET|/api/v1/accounts/:account_id/users
   2. url:GET|/api/v1/users/:id

I can see why they would need these endpoints, but we're mostly concerned about the info provided in GET|/api/v1/users/:id and GET|/api/v1/courses/:course_id/enrollments

Are there any Canvas API gurus out there that see any other concerning endpoint permissions we would be providing, or have tips on reducing the amount of info given to the vendor with scope settings?

I'm absolutely going to follow up with our VitalSource rep and the proper departments at our university and get some more specifics before we proceed, but I just wanted to see if any other university admins in the community have had any experience with roster integration. If you've done this sort of setup, how's it working for you and are there any issues to be aware of? If you've looked into the integration, but decided against it, what led your institution to that decision?

I've searched for more info in the community, but only found the same question posed about B&N roster exchange API Integration best practice- roster exchange‌ from a year ago and thought I'd give it a little bump since more and more vendors are going to want to take this route.