Canvas Roster Integrations?

[Nick_Yamagata]

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.

[kona]

 @Nick_Yamagata  greetings! I'm not sure of the answer to your question, but I'm going to share this with the Canvas Developersgroup in the Community to see if they can help. 

Kona

[Nick_Yamagata]

Thanks! I know it's a rather specific question. I've been working closely with our customer rep to iron out all of our worries, but was curious if anyone else in the community was in the same boat, or even considering the same exchange.

[agschmid]

Hi Nick,

At times I've had to figure out what the least amount of permissions are needed in order to still be able to use the needed endpoints. I usually create a new account role on beta with no permissions to start, add one of my users which does not have any admin permissions and use the following document to start applying minimal permissions, logging which of the needed endpoints are available as I add permissions:

https://s3.amazonaws.com/tr-learncanvas/docs/Canvas_Permissions_Account.pdf