Integration
Putting the timetable in your VLE
Students do not visit a timetabling system. They live in the VLE and in their calendar, and the timetable has to arrive there. This page is about the two mechanisms that do it, and about the plugin we do not publish.
Start with the honest part
We do not publish a Moodle plugin, a Canvas app, a Blackboard building block or an LTI tool. If your requirement is a block inside the VLE that we maintain and your VLE team installs, we are not the answer and you should know that on this page rather than in a meeting.
What exists instead is the thing those plugins are usually wrapping: a subscribable calendar feed per person, and a documented REST API. Every system named on this page can consume one or the other, and both are already in the product rather than on a roadmap.
What each system can do with what we publish
| System | The mechanism | What the student or lecturer sees |
|---|---|---|
| Moodle | iCalendar subscription per user, added to the Moodle calendar | Their own sessions in the calendar block, alongside assignment deadlines. |
| Canvas | iCalendar subscription per user | Their own sessions in the Canvas calendar. |
| Blackboard Learn | iCalendar subscription per user | The same, in the Blackboard calendar. |
| Microsoft Teams | The meeting link carried on the session itself | The class joins from the timetable entry. Online meeting links is the page for this. |
| Outlook and Microsoft 365 | iCalendar subscription | The timetable in the calendar they already have open. |
| Google Calendar | iCalendar subscription | The same, and on the phone without an app. |
| Apple Calendar | iCalendar subscription | The same. |
| Anything else | The REST API | Whatever your developers build. One request returns a week with rooms, lecturers and groups already filled in. |
Why a feed rather than a copy
A feed is a subscription: the student subscribes once and every later change arrives on its own. A copy is an import, and an import is out of date the first time a room moves — which on a live timetable is the same week.
This matters most for the case nobody plans for. A room change at nine in the morning has to reach the people in that room, not the people who happen to reload a page. Calendar subscriptions is how the change travels, and change notifications is what happens when it must travel faster than a calendar refresh.
The two things to check before you design around this
Who the feed is for. A feed is personal — one student’s own sessions, not the whole school’s. A timetable per student is what makes that possible, and it depends on the group structure being right.
How often the VLE refreshes it. Calendar clients decide for themselves how often to re-read a subscription, and some are slow. This is a property of the client, not of the feed, and it is the reason a change notification exists as well.
If what you actually need is the timetable on a page rather than in a calendar, that is web publishing and the student portal, and neither needs the VLE at all.
Want to see this working?
Book a 45-minute online presentation and we will walk through it against your institution's own scheduling problem.