Finding IDs and problems with {account_id}.

[dhagood]

Most API calls require some an ID. I find ID variables by making a general call (GET /api/v1/courses) that includes an ID variable, then use one of the specific IDs for further calls (this example returns {course_id} values). I've noticed that some of the IDs are displayed in the URL as well, if I access the content in the browser.

But for a some IDs, I am not sure where to find the information.

Where can I find the {account_id} value? Is that what is returned when I call GET /api/v1/accounts/search? If yes, I'm not sure how to tell account_id is related to a specific course. I'm trying calls that require the {account_id} and not getting back data. Are calls using the {account_id} generally above the TA / Instructor privileges level?

Then, in some instances a call references just {id}. For example, with GET /api/v1/courses/{id}, I would expect {id} to reference a {course_id} value. Is this correct? Is an {id} value short hand for the identifier likely related to the call? For example, in this example, I am confused why the call references {id} when there is also a {course_id} used in the API—like in requests like GET /api/v1/courses/{course_id}/students.

[James]

dhagood,

Where can I find the {account_id} value? Is that what is returned when I call GET /api/v1/accounts/search? If yes, I'm not sure how to tell account_id is related to a specific course. I'm trying calls that require the {account_id} and not getting back data. Are calls using the {account_id} generally above the TA / Instructor privileges level?

First, let me ask if you need to? In many cases, including the account, you can use self instead of the actual number. If, however, you need to work with subaccounts, then you will need to find the account id.

When you request a course, you should get the account ID as well.  For example, when I call GET /api/v1/courses/896851 on our site, I get (there's more, I cut it off)

In general, anything ending in _id corresponds to that table in the database, so account_id is the id from the account_table. The primary key for the table you're querying is just called id. If you do a lookup of an account, it will be called just id. Here, since I'm looking up a course, the id field is the course id.

Sometimes there are a pair of codes that will give you an id. For example, there may be a context_type and a context_id in some cases. When that happens, the context_id is the id for the context_type table. So, if context_type = submission and context_id = 1234, then what you're really getting is submission_id = 1234. I may be off slightly on the naming, this is an example pulled from memory without double checking.

In other places there are context codes, which look like course_1234 or group_4567. Those would correspond to the course_id=1234 and the group_id=4567.

Then, in some instances a call references just {id}. For example, with GET /api/v1/courses/{id}, I would expect {id} to reference a {course_id} value. Is this correct? Is an {id} value short hand for the identifier likely related to the call? For example, in this example, I am confused why the call references {id} when there is also a {course_id} used in the API—like in requests like GET /api/v1/courses/{course_id}/students.

Yes, mostly. The {id} is for whatever immediately precedes it in the route. There may be one distinction though. course_id is SISable and you can use something like sis_course_id:1234 instead of the Canvas ID. Whether or not a plain id can be replaced by a SIS id may depend on where it is and what it is, but I wouldn't count on it and you may need to supply the Canvas id instead.

[zia_rehman]

Using self instead of actual account id is great, but didn't see it in API docs, did i missed it or docs are missing this.

[maguire]

See https://canvas.instructure.com/doc/api/file.object_ids.html

It explains a number of the SIS ID and special ID, including the meaning of "self".