v0 und die öffentliche Center-API — Schritt für Schritt (auch ohne Entwickler-Hintergrund)
Komplett von A–Z (Redaktion, verständlich): v0-Website A–Z (für Redaktion).
Redaktion / Projektleitung: v0 + Cockpit (So geht’s) — nur Schritte; Instructions D, A, B, C, E wegen v0-Limit 10×5000 Zeichen (Teil D = Pflicht-Workflow, zuerst; E = Performance).
Diese Seite ist für alle, die mit v0 eine Website oder App „skizzieren“ sollen, die echte Center-Daten vom CockpitOS-Dashboard lädt. Technische Feinheiten (Deploy, Umgebungsvariablen) sind ausdrücklich ausgelagert — damit klar ist, was du in v0 machst und was ein Techniker übernimmt.
Nicht das Richtige? Wenn ihr nur ein neues Design fürs Cockpit als ZIP-Template wollt (Upload ins Dashboard, gleiche Seiten wie die Center-Website), nutzt den Weg unter Templates — Intro — dort ist die reine Content-Creator-Anleitung.
Kurz: Wer macht was?
| Rolle | Aufgabe |
|---|---|
| Du (Konzept / v0) | v0 bedienen: Referenzbilder, großen API-Kontext einfügen, Slug & Wünsche beschreiben, Entwurf iterieren |
| Technik (Agentur / IT) | Projekt auf z. B. Vercel ausrollen, DASHBOARD_API_URL setzen, erste API-Aufrufe prüfen, Fehlerseiten testen |
Ohne technische Person kann die fertige, öffentlich erreichbare Website in der Regel nicht zuverlässig online gehen — v0 liefert Code, aber Hosting und Konfiguration sind Handarbeit.
Schritt 1 — Vorbereitung (5 Minuten)
- v0-Account — z. B. v0.dev (oder v0 in Cursor, falls euer Team das so nutzt).
- Center-Slug kennen — der kurze Name in der URL (z. B.
beispiel-center), wie er im Cockpit angelegt ist. Optional: eine Test-Domain, falls ihr späterby-domainnutzen wollt. - API-Basis-URL klären — meist Produktion:
https://dashboard.cockpit-os.de. Staging nur, wenn eure Technik ausdrücklich eine andere URL vorgibt.
Schritt 2 — Den „API-Kontext“ in v0 einfügen
- Öffnet im Cockpit-Doku den Public Center-Website API — Vertrag.
- Scrollt zu „Copy-Paste: Kontext für v0 / KI“.
- Kopiert den kompletten Textblock (von „Baue eine öffentliche Center-Website …“ bis zu den Hinweisen am Ende).
- In v0: Neuer Chat → den Block als erste große Nachricht einfügen.
- Ergänzt in natürlicher Sprache, z. B.:
- „Nutze als API-Basis genau: …“ (eure geklärte URL aus Schritt 1)
- „Center-Slug für alle Beispiele: …“
- „Starte mit Startseite + Shop-Liste; Karte/Wayfinding erst später.“
So weiß v0, welche URLs es verwenden soll und in welcher Reihenfolge ihr vorgehen wollt.
Schritt 3 — Look & Feel (optional, aber empfohlen)
- Screenshots von Webseiten, die euch gefallen (Hero, Karten, Footer — wie bei den ZIP-Templates).
- Bilder in denselben v0-Chat legen oder kurz beschreiben: „hell, große Typo, viel Weißraum“.
- Nachjustieren: „Navigation kleiner“, „mehr Kontrast“ — normale v0-Sprache, kein Fachjargon nötig.
Schritt 4 — Technik übergeben (Checkliste)
Gebt eurer technischen Person mindestens mit:
- den exportierten Code aus v0 (ZIP / Repo-Link, je nach Workflow);
- die API-Basis-URL und ob Staging oder Produktion;
- den Center-Slug bzw. die Domain für
by-slug/by-domain; - den Hinweis auf den API-Vertrag (CORS, 429 bei Chat/Routing-POST, unterschiedliche JSON-Formen).
- optional nach Firmen-Standard — pro Center: eigenes GitHub-Repo in der Organisation
sawmuedev+ eigenes Vercel-Projekt, Zugriff für Mitarbeiter:innen per GitHub-Account; vollständige Anleitung: v0-Website A–Z, Abschnitt F2 (GitHub & Vercel).
Die Technik sollte den Vertrag kurz lesen — insbesondere Fehlercodes und den Ablauf Slug → centerId.
Schritt 5 — Was ihr nach dem Launch testen sollt (ohne Code)
- Startseite lädt, keine leere Seite / kein dauernder Ladebalken.
- Shops oder News sichtbar (je nachdem, was ihr zuerst gebaut habt).
- Mobil kurz ansehen (Layout nicht „kaputt“).
- Wenn Chat oder Wegberechnung eingebaut sind: bei sehr vielen Klicks kann kurz „Warten“ erscheinen (Rate-Limits) — das ist Schutz vor Missbrauch, kein Center-Fehler.
Häufige Missverständnisse
- „v0 hat alles verbunden“ — v0 generiert Code, der
fetchnutzen soll; ob die URL in der laufenden Umgebung stimmt, prüft die Technik (Umgebungsvariablen). - „Gleich wie ZIP-Template“ — Nein: ZIP-Templates werden ins Cockpit hochgeladen und an die bestehende Center-Website angebunden. Die öffentliche API ist für eigene Deployments (eigene Domain, eigener Next.js-Code).
- „Alles kostenlos ohne Limit“ — Chat- und Routing-Endpunkte können bei extrem vielen Anfragen 429 zurückgeben; normale Besucher sind selten betroffen.
Vertiefung
- Public Center-Website API — Vertrag — alle Routen, Parameter, Copy-Paste-Block
- Beispiel-Responses & Medien-URLs — JSON-Shapes,
logo/logoUrl, CDN,public-visitor-surface, Auth-Hinweis - Lückenanalyse — technischer Status, CORS, Prioritäten
- Templates — Intro — wenn doch der ZIP-/Cockpit-Weg gemeint ist
Nutzungsstatistik: Seitenaufrufe werden anonymisiert erfasst. Im Umami-Dashboard nach diesem Pfad filtern: /developer-guide/v0-mit-oeffentlicher-api-anleitung