...
The API documentation uses the variable $base_url
to refer to the base URL of MyTimetable. This URL depends on the customer and can be found on the Customer-specific API information page.Not
Not all MyTimetable sites have enabled API access. Some customers choose to enable API access only for certain trusted applications. Please contact us if you have questions about the API or if you would like to receive an access token for a certain API.
Data structure
A student's timetable is made up of one or more individual timetables. These timetables are all of a certain type. The exact meaning of a type depends on the customer (see Customer-specific API information), but the table below gives an idea of the options:
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 (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. |
The API gives the option to either query a user's complete personal timetable, based on his or her MyTimetable subscriptions, or a single timetable which is not based on a user's profile. The first option always requires a certain form of authentication, whereas the second option may be available without any authentication or only requires an API token. An example workflow for both scenarios:
- 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
/subscriptions
call. - Retrieve the timetable of a user using the
/timetable
call. - Add or remove subscriptions to a user's profile by using the
/subscriptions
calls. To retrieve a list of timetables that can be added, one can use the/timetables
call.
- Single timetable
- Retrieve a list of timetables for a certain type by using the /timetables call.
- The list of the previous call can be filtered using several filter options. The values for these filters can be retrieved using the
/timetablefilters
call. - After choosing the right timetable, the contents of the timetable can be retrieved using the
/timetables/<key>
call.
Multiple databases
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.
Authentication and authorisation
To set up OAuth, follow these steps:
...
...
Open a Terminal window and enter the following command (replace XXXXXX with your personal code from step 3):
Code Block | ||
---|---|---|
| ||
curl -d 'grant_type=authorization_code&client_id=test&client_secret=test&code=XXXXXX&redirect_uri=http://localhost' http://demo.eveoh.nl/oauth/token |
...
WADL
A machine readable XML based description of the API can in WADL format can be viewed using the following url:
...