Ik ben tegen hetzelfde soort problemen aangelopen, maar ik heb een andere weg ingeslagen. In plaats van direct de kalender-API-endpoints te gebruiken, bouwt mijn importer [event] BBCode en plaatst deze in Discourse, waardoor de plugin het kan parsen alsof een medewerker het evenement handmatig heeft aangemaakt. Zo vermijd ik afhankelijkheid van tijdelijke queryparameters zoals include_expired, en krijg ik een stabieler contract — gewone posts en BBCode zullen waarschijnlijk niet zonder waarschuwing veranderen.
[event start="2025-09-29 09:00" end="2025-10-29 10:00" location="Office B1"]
Ontmoeting om de Discourse RESTful API te bespreken
[/event]
De afweging is meer werk aan mijn kant: ik moest een formatter schrijven die ICS-gegevens omzet in correct ontsnapte [event]-tags, rekening houdend met de hele dag geldende of getimede evenementen, enzovoort. Maar in de praktijk is deze aanpak veel veerkrachtiger gebleken bij upgrades. Het neemt de noodzaak van upstream-verwijderingsaankondigingen niet weg (ik wil nog steeds dat API’s snel falen of op zijn minst waarschuwen wanneer opties worden verwijderd), maar het heeft wel het risico verminderd dat mijn scripts stilzwijgend breken.