...
| Type | Meaning |
|---|---|
| student | Personal timetable of a student (when available, most institutions do not have personal timetables available in their timetabling application). |
| staff | Personal timetable of a staff member. |
| module | Timetable for a module or course. |
| pos | Timetable for a programme of study (group of modules). |
| posss | Timetable for a programme of study (group of studentsets and associated modules). This is a different implementation that the pos type, and the exact type available depends on the institution. |
| studentset | Timetable for a certain group of students (usually the timetable for a class or study group). |
| studentsetgroup | Timetable for a group of studentsets student sets (most customers use either studentset or studentsetgroup to the outside world). |
| modulepos | Timetable for a certain module, but limited to the studentsets of a certain study programme. This is used if a module is shared between study programmes, but contains activities that are specific to a certain study programme. |
| user | Personal timetable for a user (can be both a student or a staff member). |
| location | Timetable for a certain (class)room. |
| zone | Timetable for a building or other grouping of rooms. |
...
- Personal timetable
- Request access to the user's personal timetable by using OAuth, or use impersonation using an API token (if available).
- Retrieve a list of a user's subscriptions using the
/subscriptionscall. - Retrieve the timetable of a user using the
/timetablecall. - Add or remove subscriptions to a user's profile by using the
/subscriptionscalls. To retrieve a list of timetables that can be added, one can use the/timetablescall.
- Single timetable
- Retrieve a list of timetables for a certain type by using the
/timetablescall. - The list of the previous call can be filtered using several filter options. The values for these filters can be retrieved using the
/timetablefilterscall. - After choosing the right timetable, the contents of the timetable can be retrieved using the
/timetables/<key>call.
- Retrieve a list of timetables for a certain type by using the
...
| Name | Description |
|---|---|
| activityDescription | The description of the activity, could be the course, module or activity name. This should be shown to the user as 'main description'. |
| moduleCode | Some customers have a separate module code available which is a (semi-) unique identifier for a certain course of module. |
| activityTypeName | The name of the activity type this event belongs to. Key value which can be used to group and colour activities. Should not be shown to the end-user directly. |
| activityTypeDescription | The description of the activity type of this event. This value should be shown to the user and indicates whether the activity is a lecture, practical, exam, etc. Not all institutions provide (sensible) activity type information. |
| startDate | Start date and time of the event. See #Output format below for the date format. |
| endDate | End date and time of the event. See below for the date format. |
| studentSets | |
| locations | |
| staffMembers | |
| notes |
...
| List of student sets (e.g., classes, groups) associated with the event. | |
| locations | List of locations associated with the event (consists of identifier, name, key and capacity). |
| staffMembers | List of staff members associated with the event. |
| notes | Some notes or additional information about the event, not all customers use this field. |
New fields may be added to objects without incrementing the version number. See API Documentation for details.
Output format
The resources support both JSON and XML. By default, the returned format depends on the HTTP Accept header. Use application/json for JSON and application/xml for XML. It is also possible to specify the output format in the URL, by appending .json or .xml to the resource name, before the query string. Dates and times are returned in ISO 8601 format (YYYY-MM-DDTHH:MM:SS±hh:mm) when retrieving results in XML, and in Unix timestamp format when retrieving JSON.
Authentication and authorisation
WADL
A machine readable XML based description of the API in WADL format can be viewed using the following url:
| Code Block |
|---|
$base_url/api/v0?_wadl |
...
Depending on the wishes of the institution, the MyTimetable API can require several forms of authentication and authorisation.
First of all, it can be necessary for the client application to provide some form of authentication. This makes sure only authorised applications can access the API data. This authorisation is usually done using an API token. Next to the client authentication, sometimes the client application wants to access the personal data of a user. The user can either provide authorise the application to access this data, using OAuth, or the client can use a special API token with elevation privileges. Some MyTimetable environment only allow API access for requests that can be linked to a real user. In these cases an OAuth token is always necessary.
In the requests below we have not included the authorisation information (like the access_token query parameter or the apiToken header). The page with Customer-specific API information lists the requirements of the different MyTimetable environments available.
WADL
A machine readable XML based description of the API in WADL format can be viewed using the following url:
| Code Block |
|---|
$base_url/api/v0?_wadl |
Version numbering
The API uses a version numbering scheme and the base URL of the API is: $base_url/api/v$version. The current API version is version 0. Non-breaking changes (like the addition of extra information or methods) will be done without incrementing the version number. On breaking changes the version number will be increased. Multiple API versions may exist at the same time. Eveoh will try to support older API versions when technically and economically feasible, but users are encouraged to always use the latest API version.
Multiple databases
Resources
/timetables
Description: Query all timetables with a specified type.
...