Leiho sert aussi votre contenu au front : WordPress reste l’unique source de vérité, et le dépôt du front contient du code, pas du contenu.

// astro.config / build script — Node 18+
import { loadLeihoContent, indexLeihoContent } from 'leiho/content';
import type { LeihoExport, Page } from './src/leiho'; // npx leiho types

const { data } = await loadLeihoContent( { url: 'https://cms.example.com' } );
const content = indexLeihoContent( data as LeihoExport );
const home = content.byPath( '/' ) as Page;
home.fields.hero_title; // typed

Endpoint	Renvoie
`GET /wp-json/leiho/v1/export`	Tous les éléments publiés des types de contenu Leiho, en une seule réponse. Mis en cache jusqu’à la prochaine modification, avec un `ETag` (un build sans changement reçoit un `304`).
`GET /wp-json/leiho/v1/content?type=&path=&slug=`	Une liste filtrée et paginée.
`GET /wp-json/leiho/v1/content/{id}`	Un élément (brouillons compris pour les rédacteurs connectés).
`GET /wp-json/leiho/v1/types`	Les déclarations TypeScript exactes de ce JSON, générées à partir de vos groupes de champs ACF.

Chaque élément contient id, type, slug, path (le chemin côté front, issu de vos réglages d’URL), title, les dates, excerpt, le content rendu, featured_image, terms et fields. Les champs sont indexés par nom et déjà mis en forme pour un front : une image donne { id, url, alt, width, height, sizes }, une relation { id, type, slug, title, path }, un WYSIWYG du HTML rendu, et une ligne de contenu flexible porte un _layout.

Une requête par build au lieu d’une par page : fini les « Error establishing a database connection » sur les hébergements mutualisés.
Instantané de secours : chaque chargement réussi est écrit dans .leiho/content.json. Si WordPress ne répond pas, le build continue avec le dernier contenu connu et le signale (fallback: 'error' pour échouer à la place).
Types : npx leiho types --url https://cms.example.com écrit src/leiho.d.ts. Régénérez-le quand vous modifiez des champs.
Accès : public par défaut (contenu publié uniquement, de toute façon public). Passez en Restreint dans les réglages et définissez LEIHO_TOKEN dans l’environnement de build.
Cache : Leiho s’appuie sur les caches dont le site dispose déjà (Réglages → API de contenu → Cache, activé par défaut).
Avec un cache d’objets persistant (Redis Object Cache, Memcached, LiteSpeed, W3 Total Cache…), l’export, les éléments individuels, les recherches par chemin et les types sont stockés dans le cache d’objets de WordPress (groupe leiho). L’invalidation est en O(1) : chaque modification fait passer à une nouvelle génération de cache au lieu de supprimer des clés. Sans cache persistant, Leiho conserve sa propre copie de l’export dans une option non chargée automatiquement, et n’écrit rien d’autre en base.
Chaque endpoint envoie un ETag et Cache-Control: public, max-age=0, must-revalidate, et répond 304 à un If-None-Match correspondant. En mode restreint, pour les utilisateurs connectés et pour les brouillons, les réponses sont private (et LiteSpeed reçoit la consigne de ne pas les mettre en cache).
Quand le contenu servi change, Leiho purge l’API de contenu des caches de page qu’il détecte, une fois par requête : LiteSpeed (par tag et par URL, Hostinger compris), WP Rocket, W3 Total Cache et WP Super Cache (par URL quand ils le permettent), SiteGround, WP Fastest Cache, Cloudflare, Breeze, Nginx Helper. Branchez-vous sur le hook leiho_purge_caches pour purger autre chose (un CDN, un reverse proxy) ; leiho_purge_urls modifie les URL purgées.
Vider le cache de contenu, dans les réglages, fait tout cela à la demande.

API de contenu