Home/Projects/Moodle and Teams aggregation
Moodle and Teams, pulledinto a single application
A web application, installable on the phone, that reads the platforms of a master's programme twice a day, archives the materials, puts deadlines in the calendar and sends a notification for every update. In two measured weeks it had no failed runs.
Where we started
One of us is enrolled in a master's programme and works two-week shifts. Information was scattered across 15 courses in Moodle, 9 teams in Microsoft Teams and a few PDF timetables. Nothing flagged a new assignment or a moved deadline.
The institution's Microsoft platform does not allow reading the calendar, messages or files through the API without administrator approval. The first version of the application, hosted outside our server, was slow to sign in, so we moved it to our own server.
The solution
- one service reads Moodle through the official interface at 07:00 and 19:00, archives files by course and creates the deadlines
- a second service reads Teams from a browser that runs permanently on the server, in read-only mode
- every update arrives as a push notification on the phone
- the application installs on Android and shows the last page even offline
- timetable, deadlines and updates sync live between devices
From platform to notification
No service is exposed directly to the internet; access goes only through a TLS proxy.
Teams without an API
A small client of our own drives a headless browser and reads only the page content.
- selectors independent of the interface language
- the session survives a server restart
Deadlines without duplicates
A deadline entered by hand and one found automatically, for the same course, on the same day and of the same type, become one.
- detection of moved deadlines
- files already archived are not downloaded again
Data kept safe
The database is a file with atomic writes, so a sudden shutdown does not corrupt it.
- daily copies kept for 14 days
- course files in our own cloud
The lost session
The institution's platform issues only session cookies, which disappear when the browser closes. We left the browser running permanently, with a persistent profile and an automatic restart within 5 seconds if it stops. After the server restart on 31 Oct 2026, the session was recovered without signing in again.
On 20 Oct 2026 Teams changed its interface. We added a second set of selectors and detection of sign-in prompts, and reading worked again the same day.
What we measured
- 0 failed runs between 21 Oct and 4 Nov 2026; in total, 2 failed Teams runs, on 20 Oct, fixed the same morning
- 63 files and 128 Moodle activities under monitoring
- 9 Teams teams detected; 23 activities and 17 posts processed
- redirect to sign-in in 0.038 s
- memory: 16.9 MiB for the application server, 47 MiB for the Moodle service
What Claude did on the project
What Claude did
- the first version of the application was a page built together with Claude
- generated the code iteratively, from our requirements
- inside the application, turns incoming messages into work tasks
- answers questions only from the project documents, citing the source, and says what is confirmed and what is an assumption
What we did
- set the requirements and made the decisions
- moved the application to our server and put it into operation
- run it and follow it day by day
- handle sign-in to the institution's accounts
If the Teams interface changes and reading breaks, the application shows a warning under Updates, and we make the fix together with Claude.
Related services and projects
Custom software
Web apps and PWAs, mobile apps and integrations with platforms that offer no API.
Dissertation platform
Topics, stages, versioned documents, comments and committees, on the same server and with the same approach.
AI email assistant
8 email accounts managed on our own server, with an hourly AI summary.
See also how we work with Claude.
Do you check several platforms by hand every day?
We can read them automatically, even without an API, and send you only what is new.