Integration

The Wise Timetable REST API

Anything Wise Timetable publishes can be read as JSON over HTTPS — by your portal, your VLE, your own app, an information screen or a reporting tool. The manual is public, so your developers can judge the integration before anyone signs anything.

Book an online demo Download the free trial

API v2, JSON over HTTPS
30-page manual, ungated
ETag caching, 304 when nothing changed

You can inspect it right now

The service description needs no credentials, so the first question a developer asks is answerable in one line.

GET https://wise-tt.com/api/v2/meta returns the service name, the version and the list of endpoints the server is currently serving. No token, no account, no sales call — open it in a browser. It is also the honest way to discover anything added after the manual was last revised.

The 30-page integration manual is published in full, ungated, with every endpoint's parameters, a realistic example response for each, and complete working examples in curl, Python, JavaScript and C. We publish it because an integration that looks feasible on paper and turns out not to be is a far more expensive discovery in month three.

Reading data does require an API account, issued by us and scoped to the schools it may read. That part is deliberate: a timetable names who teaches what and which students attend it.

One request per view, not a chain of them

GET /v2/schedule takes a school, a date range and what you are following — groups, a lecturer, a room, a course, or nothing at all for the whole school — and returns every event in the range with its rooms, lecturers, groups and branches already filled in, together with the school's holidays and the bounds of the published academic year. There are no follow-up calls to resolve ids into names.

Measured on the largest school on the server, one week is about 100 kB and 75 ms. The range is capped at 400 days per request, which is what makes the worst case knowable rather than a surprise on the day somebody asks for a decade.

Event ids carry their kind in the first character: S for a timetabled lesson, R for a reservation — an exam, a room booking, a meeting, a lab session.

What the API exposes

Schedules, by student group, lecturer, room or course — or the whole school at once
Full detail for a single event, including the programme, year, branch and group hierarchy behind every group attending it
The bounds of the published academic year, so a client can stop the user navigating into weeks that cannot hold data
Holidays, so an empty day reads as a holiday rather than as missing data
Notifications attached to a school, a group, a course or a lecturer, deduplicated and returned as structured objects
Code lists for programmes, branches, groups, lecturers, rooms and courses — the ids and labels a picker is built from
Room capacity, room code and the school's own room mailbox, where the school has filled them in
The school's bell schedule, because slot lengths are not the same everywhere
What each school permits a client to offer, so a browse-by-lecturer picker is hidden where lecturer engagements are treated as confidential

And two things you can write back

The API is read-mostly, and the exceptions are named. POST /v2/eventlinks attaches an online-meeting link to individual events by their stable identifier — the link survives the next re-publish from the desktop application, and a link entered by the timetabler wins over a pushed one. POST /v2/student-registration lets a student information system state which groups and course sittings a student belongs to.

Both are off unless your account is explicitly permitted to use them, and both report per-item results rather than failing the whole batch because one course code was mistyped.

Built for a client that polls

Every response carries an ETag. Repeat the request with If-None-Match and an unchanged timetable answers 304 with no body at all, which is the common case for a screen in a foyer refreshing every few minutes. A well-behaved client transfers almost nothing on a quiet day.

Credentials are exchanged once for a bearer token that lasts 24 hours and encodes the schools it may read. Browser applications are supported through an explicit origin allow-list rather than a wildcard — tell us the origin your dashboard is served from and it is added.

Errors that say which thing went wrong

A mistyped school code, a school your account may not read, and a week that genuinely has no lessons in it are three different situations, and an integration that shows the same message for all three wastes somebody's afternoon. They are 400 unknown_school, 403 school_not_permitted and a perfectly ordinary 200 with an empty list.

Every failure returns a stable machine-readable error code, a sentence in English, and often a hint. A 500 carries a reference id; quote it and the exact log lines can be found immediately.

The older surface is still served, and still frozen

Institutions that integrated against the earlier API did not have their integration broken by v2. The legacy paths are still served and are frozen deliberately, and v2 keeps the legacy field names on purpose — so moving to v2 is a change of URL rather than a change of parser, and the fields v2 adds are additions rather than replacements.

That is the whole policy in one sentence: an API a university builds against is a promise, and breaking it to tidy up field names is not a saving.

Download the API manual

See Wise Timetable on your own data

Book a 45-minute online presentation. We will walk through your institution's scheduling problem, show how Wise Timetable handles it, and answer anything your team wants to test.