@adam_marshall
You do have to be an admin for the root account to get all of the courses in the account, but you will never get all the courses in the account through the courses API. That is scoped to the user making the call. If an admin makes the call, but is not enrolled in any courses, then they get a empty list through the courses API that David originally listed. I just verified this with one of my system accounts that is not enrolled in any courses and the call came back as an empty array []. While, being an admin is part of the solution, it's not the full solution.
Suggesting per_page=1000 will likely confuse people more than it helps. Most API calls are limited to 100, not 1000. Telling people to put an arbitrarily large number in there may make them think they will get all of them, when they won't get more than 100. Early on, we saw people in the Developers Group who were touting the 1000 and automatically using page=2, page=3, etc, thinking they will eventually run out of responses and can stop. That does not work and we've tried to correct people's understandings when we encounter it.
What people need to do is look at the link headers that are returned in the response as explained in the pagination documentation.
The default number of responses is usually 10, so in a case where someone mentions getting a partial set of responses and then says "it's only giving me 10", pagination is the most common solution. Probably the the best thing to do in a case where there is a possibility that pagination is an issue is to refer them to the documentation along with a mention that this may be an issue if they're only seeing 10 of their items. If you want to provide a more complete statement, you could write that if they are only getting 10 responses, then pagination may be the cause and that they can get up to 100 with per_page=100 but will need to use the pagination documentation (with link) to get more than that.
It is once we know that pagination is the issue and people are struggling with it that we give a more complete explanation. This may optimization tips. Optimization does not necessarily mean the most courses in one request. It might be showing how the same request can be made with GraphQL, which typically returns the contents faster and you can get more than 100 responses.
For example, this will return the first 1000 courses in an account, giving their Canvas course ID in the _id field. Replace the id in the query because your account ID is not 97773.
query accountCourses {
account(id: "97773") {
coursesConnection(first: 1000) {
nodes {
_id
sisId
state
name
}
pageInfo {
hasNextPage
endCursor
}
}
}
}
That also returns page information that you can check to see whether you need to do more. In my case, hasNextPage was true and the endCursor was "MTAwMA". That means I could make the request adding the after parameter to the coursesConnection conditions.
coursesConnection(first: 1000, after: "MTAwMA")
By the way, "MTAwMA" is just a base64 encoding of "1000".
Note that I said that GraphQL typically returns the results faster. For me, it took around 26 seconds to return 1000 courses with just the limited information I requested.
In this case, it took about 1.3 seconds to get 100 courses using the REST API /api/v1/accounts/self/courses?per_page=100&page=21. The reason I specified 21 was to bypass the any caching of the first 2000 that I had already made with GraphQL. If I made the same GraphQL that took 26 seconds again, it takes about 2 seconds.
I could taken 13 seconds to fetch 1000 courses using the REST API vs 26 seconds with GraphQL. In other places, GraphQL really shines.
You could also leverage the pagination. What I do for listing all of my courses in the account is to make one fetch of 100, look at the pagination, and hope there is a last attribute for the link header. If so, I can make the rest of my requests asynchronously with enough delay that I don't run into the throttling issue. If I allow for 5 concurrent requests spaced 200 ms apart, I can probably get 1000 within 4 seconds and not be stopped out by throttling.
Another thing to remind @DavidGeismar2 of is the availability of the admin reports. It may not be appropriate for his situation. Because he specifically mentioned the API, neither Melody or I mentioned the report. However, if someone is looking for an as-needed report of what has is in your instance, you can go to Admin > Settings > Reports and use the Provisioning report to get a list of everything in your instance.
If you're doing something that is going to be done regularly or that you need a list so you can iterate through it and don't want to mess with the report, then the API is how to get that information.
