How to Integrate Lovable with TYPO3

The TYPO3 Headless Extension must be installed and configured on your TYPO3 server before you can call its API. If your TYPO3 administrator has not yet set this up, the installation steps are: install via Composer (composer require friendsoftypo3/headless), activate the extension in TYPO3 Extension Manager, and configure the site's headless mode in the TYPO3 Site Configuration (each Site Configuration file at config/sites/{site}/config.yaml needs headless: true added). Once installed, the TYPO3 Headless Extension exposes API endpoints under your TYPO3 installation's domain. The main endpoint for page content is: GET https://your-typo3-site.com/?type=834 (the 834 page type is the headless content type registered by the extension). For navigation, it is ?type=835. These are query-parameter based endpoints for compatibility with all TYPO3 URL configurations. Alternatively, with clean URL configuration, the endpoints can be path-based like https://your-typo3-site.com/api/page and https://your-typo3-site.com/api/navigation. The exact URL format depends on your TYPO3 site's TypoScript configuration. In Lovable, click '+' next to Preview to open the Cloud panel, then click 'Secrets'. Add: - TYPO3_SITE_URL — your TYPO3 installation base URL (e.g., https://www.yoursite.com) - TYPO3_API_KEY — an API key if your TYPO3 headless setup requires authentication (optional, depends on configuration) Verify the setup by visiting https://your-typo3-site.com/?type=834&slug=/ in a browser — it should return a JSON object with page and content data.

The Edge Function proxies requests to TYPO3's headless API, handling CORS (TYPO3 is on a different domain from the Lovable frontend) and adding any required authentication headers. The function accepts parameters for the page slug (or UID) and language ID, constructs the TYPO3 API URL, fetches the JSON response, and returns it to the frontend. TYPO3's headless API response structure differs from WordPress. The response contains a 'page' object with page metadata and a 'content' object with colPos-keyed content element arrays. Content elements have a 'component' field (matching the CType) and 'data' field with the content. Your React components need to handle each content element type (header, text, textpic, image, bullets, table, media, etc.) based on the component type. The navigation endpoint (?type=835) returns the full page tree in a nested format useful for building navigation menus, breadcrumbs, and sitemaps. Cache the navigation response as it changes rarely. The slug parameter maps to TYPO3 page slugs configured in the URL Routing of your TYPO3 site. If your TYPO3 site uses the older uid-based URL system, pass the page UID as the 'id' parameter instead.

1// supabase/functions/typo3-proxy/index.ts
2const corsHeaders = {
3  'Access-Control-Allow-Origin': '*',
4  'Access-Control-Allow-Headers': 'authorization, x-client-info, apikey, content-type',
5};
6
7Deno.serve(async (req) => {
8  if (req.method === 'OPTIONS') return new Response('ok', { headers: corsHeaders });
9
10  try {
11    const { slug = '/', lang = 0, type = 834 } = await req.json() as {
12      slug?: string; lang?: number; type?: number;
13    };
14
15    const siteUrl = Deno.env.get('TYPO3_SITE_URL')!.replace(/\/$/, '');
16    const apiKey = Deno.env.get('TYPO3_API_KEY');
17
18    // Build TYPO3 headless API URL
19    const params = new URLSearchParams({
20      type: String(type),
21      slug: slug.startsWith('/') ? slug : `/${slug}`,
22      L: String(lang),
23    });
24
25    const url = `${siteUrl}/?${params.toString()}`;
26    const headers: Record<string, string> = { 'Accept': 'application/json' };
27    if (apiKey) headers['X-Api-Key'] = apiKey;
28
29    console.log(`Fetching TYPO3 API: ${url}`);
30    const typo3Response = await fetch(url, { headers });
31
32    if (!typo3Response.ok) {
33      console.error(`TYPO3 API error ${typo3Response.status} for slug: ${slug}`);
34      return new Response(JSON.stringify({ error: `TYPO3 API returned ${typo3Response.status}` }), {
35        status: typo3Response.status,
36        headers: { ...corsHeaders, 'Content-Type': 'application/json' },
37      });
38    }
39
40    const data = await typo3Response.json();
41    return new Response(JSON.stringify(data), {
42      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
43    });
44  } catch (error) {
45    console.error('typo3-proxy error:', error);
46    return new Response(JSON.stringify({ error: String(error) }), {
47      status: 500,
48      headers: { ...corsHeaders, 'Content-Type': 'application/json' },
49    });
50  }
51});

TYPO3 content elements come in many types (CTypes), and the headless extension maps each CType to a 'component' value in the JSON response. Your React frontend needs to handle each content type with an appropriate component. The most common TYPO3 content types you will encounter are: - header — headline with optional subheader and link. Data includes header, subheader, headerLayout (h1-h6), and link. - text — body text. Data includes bodytext (HTML string from RTE). - textpic — text with image. Data includes bodytext, imageorient (image position), and gallery with image data. - image — standalone images. Data includes gallery.rows with image objects. - bullets — unordered or ordered lists. Data includes bullets array. - table — HTML table. Data includes bodytext (HTML). - media — embedded video/audio. Data includes assets with file references. - menu_* — page menu variants for navigation components. The headless extension structures content in colPos groups — content assigned to different page column positions. colPos 0 is the main content area, colPos 1 is typically a sidebar. Your React components should map to the appropriate column. Ask Lovable to build a content renderer component that uses a switch statement on the component type to render different React components for each TYPO3 CType. Describe the content types used on your specific TYPO3 site.