Rather than maintain a separate adapter for every TYPO3 jobs extension, install a single BAconn reader extension on your TYPO3 site — it auto-detects which jobs extension is in use and exposes a unified REST contract.

Reader extension contract

The extension exposes three endpoints under /api/baconn/v1/:

  • GET /health — returns detected schema + extension version
  • GET /fields — lists available fields with types for the mapping UI
  • GET /jobs?since=iso8601 — paginated job list, optionally incremental

Auth via API key in X-API-Key header.

Setup

  1. TYPO3 site: install the reader extension (Composer: composer require baconn/typo3-reader, or via TER manager). In the backend → Extensions, activate.
  2. Configure extension: generate API key (extension's backend module). Optional: pick which jobs extensions are active if several run in parallel.
  3. BAconn: "New source" → TYPO3 → enter base URL + API key. "Test connection" loads the detected schema.
  4. Set up field mapping — the TYPO3 reader extension exposes language-neutral field IDs.

Reader extension status

As of 2026-04: the reader extension is in preparation as a separate TER package. Until it's released, TYPO3 customers can use the JSON-LD adapter where pages render schema.org markup (typical of many TYPO3 themes).

Why a reader extension instead of direct DB access

TYPO3 sites often have custom extensions (RKW Jobs, custom Extbase, t3blog-jobs, etc.) with different table structures. A reader extension on the customer side is the only future-proof bridge — updates to the jobs extension don't break sync because the reader extension absorbs schema drift.