Dieser Guide richtet sich an Entwickler, die Flyo Nitro CMS zum ersten Mal einsetzen. Du lernst, was du in der Flyo-Oberfläche vorbereiten musst, wie du den richtigen Token holst, welches SDK für dein Framework passt und wie die drei zentralen API-Endpunkte funktionieren.
Grundlagenwissen
Du solltest wissen, was ein Headless CMS ist und grundlegende Kenntnisse in Webentwicklung mitbringen. Flyo-spezifische Konzepte wie Entitäten, Content Pools und Integrationen werden in den verlinkten Seiten erklärt.
Voraussetzungen
Bevor du mit der Entwicklung beginnst, benötigst du:
- Einen Flyo-Account auf flyo.cloud
- Eine konfigurierte Nitro-Integration in deiner Flyo-Organisation (Integrationen → Neue Integration → Nitro CMS)
- DEV-Token und PROD-Token der Integration — diese findest du in den Einstellungen deiner Nitro-Integration
Mehr zu den Tokens (Unterschied DEV vs. PROD, Caching, Live-Preview) findest du unter Authentifizierungs-Token.
Schritt 1 — Inhaltselemente (Blöcke) erstellen
Bevor du im Frontend irgendetwas rendern kannst, musst du in Flyo definieren, aus welchen Inhaltselementen (auch «Blöcke» oder «Komponenten» genannt) deine Seiten aufgebaut werden sollen.
Ein Inhaltselement entspricht einer wiederverwendbaren Komponente auf deiner Website — zum Beispiel ein Hero-Bereich, eine Karten-Grid oder ein Kontaktformular. In Flyo definierst du einmal, welche Datenfelder diese Komponente hat. Im Frontend implementierst du dann, wie sie gerendert wird.
Was ein Inhaltselement ausmacht
Jedes Inhaltselement hat:
| Bestandteil | Beschreibung | API-Schlüssel |
|---|---|---|
| Identifier | Eindeutiger technischer Name (snake_case), z.B. hero_image | identifier |
| Komponenten-Name | Camel-Case-Name für komponentenbasierte Frameworks, z.B. HeroImage | component |
| Content | Die eigentlichen Inhaltsfelder (Titel, Text, Bild, …) | content |
| Config | Darstellungsoptionen (Farbe, Grösse, Variante, …) | config |
| Items | Array aus einem Entitäts-Content-Pool, z.B. eine Liste von News-Beiträgen | items |
| Slots (optional) | Verschachtelte Platzhalter für weitere Inhaltselemente (z.B. linke/rechte Spalte) | slots |
Inhaltselement anlegen
In der Flyo-Oberfläche gehst du zu deiner Nitro-Integration → Konfiguration → Inhaltselemente (Komponenten) und erstellst dort deine Bausteine.
Empfehlung für den Einstieg
Starte mit 2–3 einfachen Inhaltselementen ohne Slots oder Items — zum Beispiel ein hero mit Titel und Bild sowie ein text_block mit Text. Das reicht für eine erste funktionierende Seite.
Alle Details zur Konfiguration von Inhaltselementen: Inhaltselemente (Komponenten)
Schritt 2 — Container und Seiten anlegen
Seitencontainer
Seitencontainer sind die oberste Strukturebene deiner Website in Flyo. Sie entsprechen in der Regel Navigationsbereichen wie «Hauptnavigation» oder «Footer». In der API werden Container im Config-Endpunkt zurückgegeben und enthalten die hierarchische Seitenstruktur.
Erstelle in der Nitro-Konfiguration → Seitencontainer mindestens einen Container (z.B. nav als Identifier).
Erste Seite anlegen
Wechsle in den CMS Editor deiner Nitro-Integration. Dort kannst du:
- Eine neue Seite in einem Container anlegen (z.B. «Home» mit Slug
home) - Inhaltselemente (Blöcke) auf der Seite platzieren und mit Inhalten befüllen
- Die Seite speichern — ab diesem Moment ist der Inhalt über den PROD-Token verfügbar
Mehr zum CMS Editor: Nitro CMS Editor
Schritt 3 — Token holen
In der Konfiguration deiner Nitro-Integration findest du zwei Tokens:
| Token | Verwendung |
|---|---|
| DEV-Token | Lokale Entwicklung und Staging. Liefert auch noch nicht gespeicherte Änderungen. Kein Caching → langsamere Antwortzeiten. |
| PROD-Token | Produktionsumgebung. Nur gespeicherte Inhalte. Mit Caching → sehr schnelle Antwortzeiten. |
WARNING
Der PROD-Token sollte ausschliesslich auf der produktiven Domain verwendet werden. Für Entwicklung und CI/Staging immer den DEV-Token einsetzen.
Alle Details zu Tokens und Live-Preview: Authentifizierungs-Token
Schritt 4 — SDK / Framework wählen
Für die meisten gängigen Frameworks gibt es ein fertiges Flyo Nitro SDK oder Adapter. Wähle das passende SDK für dein Projekt:
PHP
| Paket | Links | Beispielprojekt |
|---|---|---|
| Flyo Nitro PHP SDK | GitHub · Packagist | — |
| Flyo Nitro Laravel | GitHub · Packagist | laravel-zooexample.com |
| Flyo Nitro Yii2 | GitHub · Packagist | yii2-zooexample.com |
JavaScript / TypeScript
| Paket | Links |
|---|---|
| Flyo Nitro JS SDK | GitHub · NPM |
| Flyo Nitro TypeScript SDK | GitHub · NPM |
| Flyo Nitro JS Bridge | GitHub · NPM |
Vue / Nuxt
| Paket | Links | Beispielprojekt |
|---|---|---|
| Flyo Nitro Vue3 | GitHub · NPM | — |
| Flyo Nitro Nuxt | GitHub · NPM | nuxt-zooexample.com |
Next.js
| Paket | Links | Beispielprojekt |
|---|---|---|
| Flyo Nitro Next.js | GitHub · NPM | Playground |
Astro
| Paket | Links | Beispielprojekt |
|---|---|---|
| Flyo Nitro Astro | GitHub · NPM | astro-zooexample.com |
Die vollständige SDK-Übersicht inkl. Bridge-Bibliothek: SDKs für Flyo Nitro CMS
Die 3 Endpunkte verstehen
Die Nitro CMS API besteht im Kern aus drei Endpunkten. Alle Anfragen werden mit deinem Token als Bearer-Token authentifiziert (Authorization: Bearer <TOKEN>).
Basis-URL: https://api.flyo.cloud/nitro/v1
1. Config-Endpunkt /config
Liefert alles, was global für die gesamte Website gilt:
containers— Navigationsstruktur (Seiten, Slugs, Hierarchie)pages— Flaches Array aller gültigen Seiten-Slugs (zur 404-Erkennung)globals— Globale Inhalte (z.B. Footer-Daten, Standortlisten)nitro— Metadaten der Integration (Domain, Version, Sprache)
Der Config-Endpunkt wird einmal beim Start geladen und kann aggressiv gecacht werden. Zur Cache-Validierung nutze den Version-Endpunkt.
→ Config-Endpunkt Dokumentation
2. Pages-Endpunkt /pages/{slug}
Liefert alle Inhaltselemente einer bestimmten Seite:
json— Array der Inhaltselemente mitidentifier,component,content,config,items,slotsmeta_json— SEO-Metadaten (Title, Description, OG-Image)breadcrumb— Brotkrümel-Navigation
→ Pages-Endpunkt Dokumentation
3. Entities-Endpunkt /entities/{uniqueid}
Liefert einen einzelnen Inhalt (z.B. einen Blog-Artikel) mit allen gemappten Feldern:
- Abfrage per
uniqueIdoderslug(+ optionaletypeIdfür eindeutige Zuordnung) - Enthält die gemappten Felder im
model-Objekt - Inklusive
breadcrumb,jsonld(Schema.org) undtranslationfür mehrsprachige Seiten
→ Entities-Endpunkt Dokumentation
Abfrage-Ablauf
Bei jeder Seitenanfrage gilt diese Reihenfolge:
1. Config laden (oder aus Cache)
2. Route-Typ bestimmen (App-Route / CMS-Page / Entity-Detailseite)
3a. CMS-Page: Prüfen ob Slug in config.pages → Pages-Endpunkt aufrufen
3b. Entity: Entities-Endpunkt per uniqueId oder slug aufrufen
4. Seite rendern (Layout aus Config + Inhalt aus Page/Entity)Ein ausführliches Konzept-Diagramm und Pseudocode: Nitro CMS Konzept
Nächste Schritte
Wenn deine erste Seite läuft, lohnen sich folgende Themen:
| Thema | Beschreibung | Dokumentation |
|---|---|---|
| Live-Preview / Bridge | Automatischer Seiten-Reload im Editor, visuelles Highlight von Blöcken | SDKs & Bridge |
| Routing für Detailseiten | Entitäts-Detailseiten mit Slug oder UniqueID | Routing |
| Mehrsprachigkeit | ?lang=-Parameter, Slug-Prefixe, Übersetzungslinks | Mehrsprachigkeit |
| Caching | Version-Endpunkt zur Cache-Validierung | Version-Endpunkt |
| Breadcrumbs | Automatisch generierte Navigationspfade für Detailseiten | Breadcrumbs |
| Sitemap & Suche | XML-Sitemap und Volltextsuche | Weitere Endpunkte |
| OpenAPI | Vollständige API-Spezifikation mit deinen Entitäts-Schemas | nitro-openapi.flyo.cloud |