Dynamic Data Integration

Each widget is a CmsWidgetDataConfig document tied to a CmsSite, with a discriminated `widget_type` field and a type-specific data_source config (filters, org_node scope, time range, display options, cache TTL, auto_refresh). Editors configure a widget via the admin (POST/PATCH `/cms/sites/{id}/widgets`), drop the corresponding block into a page, and the renderer fetches at build/revalidation time from a public endpoint at `/public/cms/sites/{id}/widget-data/<widget>` or by saved config id. Ten widget types are live: ranking table (auto-updated standings filtered by competition, category and season), competition calendar (filtered by event type, org_node, time range), results (top-3 finishers per competition with type filter), club directory (region filter, contact and map display), venue map (type filter, auto-center, terrain count), live scores (during competitions, with mene detail and court display), player profile (club filter, stats enriched from PlayerStatistics), federation statistics (configurable metrics with trend data from FederationReport), upcoming events (event type filter, location and description) and sponsor banner (tier and entity filter, tiered logo sizing).

Cache TTL per widget balances freshness against load — live scores poll every 15s while club directory caches for 24h. All widget data flows through the public API which respects the same tenant scope and visibility rules as the rest of the platform, so a widget on a club site cannot accidentally expose another tenant's data. Audit trail covers widget config CRUD.

On the frontend, each widget has a dedicated React component (LiveScoreBlock, PlayerProfileBlock, FederationStatsBlock, etc.) styled to match the active TenantBrandStyle so widgets feel native rather than embedded.