kuferweb for TYPO3

kuferweb is the bridge between the Kufer back office system and the public TYPO3 website

Adult education centres, training providers and academies have managed their course operations in specialist software for decades, and in many houses that software is called Kufer. Kufer covers the full course lifecycle: lecturer management, course planning, room allocation, participants, billing, certificates. For the website this means a standard task: the course catalogue maintained in the back office should be visible on the TYPO3 website up to date, including filter search, detail views and online registration.

The audience is clearly defined: continuing education institutions with an existing Kufer tenant that run their website on TYPO3. A typical setup is an adult education centre with around 2,500 courses per semester and half a dozen course managers who maintain their courses themselves in Kufer. Without a clean integration, the website catalogue stays outdated, double maintenance becomes the default, and registrations land in a separate system that nobody likes.

Typical use cases

A first scenario is the automatically updated course catalogue. An adult education centre with 2,500 courses per semester wants every new course, every price change and every lecturer change to appear on the website without manual intervention. An hourly sync job pulls the current course data from Kufer, writes it into a TYPO3 table and updates the search. Editors no longer maintain courses in the TYPO3 backend.

A second scenario is direct online registration. A training provider with funded programmes wants to lead prospects directly from the course detail page into a registration process that calls the Kufer API in the background and registers the participant in Kufer. TYPO3 serves as the frontend, Kufer remains the source of truth, and the editorial team sees the new registration status in its familiar interface.

A third scenario is filter search with subject-specific facets. An academy with 40 subject areas and several thousand courses wants to let prospects search by category, location, date, lecturer and price tier. The search runs on the TYPO3 page against a local index that is built from the Kufer export, fast and independent of the availability of the specialist application.

A fourth scenario is multilingual course output. A language school with locations in Germany, Austria and Switzerland maintains courses in Kufer in German only and wants to offer a multilingual display on the website for prospects. The integration handles the mapping onto TYPO3 language variants, complements the German Kufer fields with manual translations in the CMS editorial process and ensures that changes in Kufer do not overwrite the local translations.

Technical architecture

kuferweb integrations in TYPO3 are almost always custom developments, because the data structures vary per Kufer tenant and the API versions have changed several times over the years. The standard approach is a lean Extbase extension with three pillars: a service layer that encapsulates the Kufer API, a persistence layer that mirrors courses in TYPO3 tables and a presentation layer that provides Fluid templates for list, filter and detail.

Synchronisation runs through a TYPO3 scheduler task. For large catalogues, a delta import is recommended that only transmits courses changed since the last run. The Kufer API usually delivers a timestamp or change identifier per course that is used for delta detection.

Online registration requires an additional API path and clean error handling. The Kufer API can respond slowly under load, so registrations typically run asynchronously: the form drops the registration request into a queue, a worker process transmits it to Kufer, and the participant receives a confirmation email as soon as Kufer has acknowledged the registration.

Common problems and solutions

The first problem is field variation between Kufer tenants. What is called “event number” in tenant A is “course code” in tenant B and “booking number” in tenant C. The solution is a configurable field mapping in the TYPO3 extension that is adjusted per installation and does not sit hard-coded in the code.

The second problem is data quality in the course catalogue. Editors do not always maintain complete texts in Kufer: short descriptions are missing, images are not attached, target audiences are not defined. On the website these gaps then appear as empty fields. The solution is a validation layer during synchronisation that flags incomplete courses in the backend and prompts the editorial team to fill them in.

The third problem is cancellation logic. When courses are cancelled in Kufer, they should disappear from the website or at least be marked as cancelled. The solution is to explicitly set cancelled courses to a status in the sync that is hidden in the list, and to attach a redirect on the detail page to a category overview.

A fourth problem is the real-time capacity display. Prospects see “3 seats left” on the website, although the booking has already moved onto the waiting list in the background. The solution is to read the capacity display not from the sync cache but to fire a small live call to Kufer on every detail page access, with aggressive caching (30 to 60 seconds) and a fallback to the last known cache value if the API does not respond.

Migration and version compatibility

kuferweb integrations run on TYPO3 v11, v12 and v13, provided the API connection is built in a modern way. The most common pain point is not the TYPO3 version but the Kufer version: when the adult education centre migrates its Kufer tenant to a new version, API endpoints and data structures occasionally change, which requires a readjustment of the TYPO3 integration.

Gosign builds kuferweb integrations on the basis of the current Kufer API, checks compatibility with the customer tenant before project start and sets up the integration modularly, so that future API upgrades do not require a large-scale rebuild. With AI support, the API client code emerges in hours rather than days, which makes the rollout realistic in two to three sprints on most projects.