The Instructure Community will enter a read-only state on November 22, 2025 as we prepare to migrate to our new Community platform in early December. Read our blog post for more info about this change.
Found this content helpful? Log in or sign up to leave a like!
Hello fellow Devs,
I've been doing integration work on our universities lecture capture system. While using the API to List Courses for a User and including the term parameter, I get back the terms successfully, however the start_at field for all of the courses are null. When using Get a Single Course while including term it does successfully return the start_at field. Also, when I List Enrollment Terms I also get the correct start_at field. I've attached screenshots of the data retrieved from these calls. I've currently got a ticket logged with our Canvas support team to look into this issue.
List Enrollment Terms
Get a Single Course (not related to user)
List courses for a user:
So, my main question is have anyone had to deal with something like this? I assume this might be a bug, but am I missing something? Is there some sort of inheritance that would lend itself to overwriting the start_at field on the List Courses for a User level instead of the Get a Single Course level?
Thanks,
Jerry
EDIT:
I've added green boxes around the course start/end date. If those were available, I wouldn't even have to worry about the terms. Hopefully I can get an answer from the migration team on why they don't exist in the first place. Thanks everyone!
Solved! Go to Solution.
Here's are more details about what I'm seeing
Here are the course listings for me, where I'm an instructor.
The items in the red rectangles with square corners are for the course. The items in the green rectangle with rounded corners are for the term.
The term dates do not match the start and end of the term, which in our case mostly correspond to the dates in the red boxes for the course because we specify the dates for the course based on the term dates.
The dates in the green box are for the term and the start_date is null because we don't limit access before the course for the instructor in the Admin > Terms page.
Here is the same course for a student
This time, the term settings match the term settings for a student. We set the course start to the start of the term, while the end of the term is a few days after the end of the course.
I think pklove is probably right as it would be really easy to miss the "term" heading and think the "start_at" applied to the course rather than the term.
Your screenshots didn't come through. Without researching this, it does sound a little like an issue I had. I asked Canvas about it and got an answer back that it wasn't a bug, it was a misunderstanding on my part. It had something to do with the dates being for the user and not the course. If a teacher could access the course from whenever, because there is no date specified in the terms (Admin > Terms), then it would come back as null.
This sounds like the term start_at date, rather than the course start_at date.
As James has said, this varies according to the user's role, which makes sense.
Jerry, can you clarify whether you really mean the course start_at date or do you mean the term start_at date?
It would have helped to have had those screenshots huh? Long day, haha. Editing the OP to include them.
I just tried getting the courses for a user with the include term parameter:
/api/v1/users/sis_user_id:some_id/courses?include[]=term
and the course dates seem to have come back fine. Certainly not null.
Oops, I meant to say 'terms are null' not 'courses are null' I'll edit the OP.
Here's are more details about what I'm seeing
Here are the course listings for me, where I'm an instructor.
The items in the red rectangles with square corners are for the course. The items in the green rectangle with rounded corners are for the term.
The term dates do not match the start and end of the term, which in our case mostly correspond to the dates in the red boxes for the course because we specify the dates for the course based on the term dates.
The dates in the green box are for the term and the start_date is null because we don't limit access before the course for the instructor in the Admin > Terms page.
Here is the same course for a student
This time, the term settings match the term settings for a student. We set the course start to the start of the term, while the end of the term is a few days after the end of the course.
I think pklove is probably right as it would be really easy to miss the "term" heading and think the "start_at" applied to the course rather than the term.
Well, it would have helped if I actually included the screenshots, but yours look exactly like mine, and explain the issue. However, there is one issue with our courses not having a start or an end date field, hence why I resorted to grabbing the term on the courses instead. I suppose I can follow up on another team to determine why the courses that are being imported don't have course start/end dates, only term start/end dates.
In a sense then, the term start and end dates for a particular user corresponds to the terms access control for that type of user enrolled in a course? ie. it will return null wherever it says 'whenever' in this portion of the terms list:
Now, if only there was a 'Get Term' api call, where you could get a term from a canvas ID, I could make a workaround for this, but I suppose the more complete solution would just be to get the import team to set the course start and end dates and use those.
Thanks so much for your very complete answer!
Now, if only there was a 'Get Term' api call, where you could get a term from a canvas ID, I could make a workaround for this
A workaround for there not being a term GET, is to do a PUT.
If you also know the term's id and name, or sis_term_id, you can do a PUT. This will return the full term object.
There is a Get Terms (plural) API call, but you'll have to scan it for the one that you want. It does not work if you tack an ID on the end. It's List enrollment terms from the Enrollment Terms API. Depending on how your terms are created, it may not take long to get the needed term. The source code shows that they are sorted by start_at, end_at, and id, with the start_at and end_at fields being in descending order (reverse chronological order). For us and only three terms a year, we would hit the current term without having to mess with pagination.
I also like Peter's trick of doing a PUT; I hadn't thought of that. At first I didn't see why Peter said you had to know something else until I tried it. The reason was that you can't do just PUT without a payload, you have to specify something or it returns a 400 Bad Request message. What Peter knows about API and LTI makes me feel like a "C" student.
Another trick some of us use is to keep a local cache of Canvas IDs in our own databases. In other words, I don't need to query what's in Canvas for the term or course start for most things because I have that stored locally and use it for most things. An instructor can change it inside Canvas and open their class up a week early, but all processing with the SIS is determined by the dates on my local copy, not what the teacher does. For things that need to be portable so that other institutions can use it, I obviously don't have that luxury and have to look up things through the API.
As far as the dates go, there is a coalesce ran on the section date, the course date, and the term dates. The first one that is not null is the one that is used. So, if you're not specifying section or course dates, then it uses the term dates, which probably explains why the course start_at and end_at were showing up null. We only specify course dates on our end, except for a special section we put everyone in who hasn't completed the mandatory student orientation to Canvas. That shows them that they have the course, but won't let them into it until the complete the orientation.
Community helpTo interact with Panda Bot, our automated chatbot, you need to sign up or log in:
Sign inTo interact with Panda Bot, our automated chatbot, you need to sign up or log in:
Sign in