Deploy-API

Übergib deine Website als ZIP direkt an ProntoSite – ohne Dashboard. Ideal, wenn du lokal (z. B. mit KI) bearbeitest und den Stand per Kommandozeile veröffentlichen willst.

Verfügbar ab dem Starter-Plan (wie SFTP; Free ohne) – für die Selbstbedienung des Kunden. Ausnahme Betreuer: Ein Admin/Partner kann im Konto-Detail plan-unabhängig ein Token erzeugen (auch für Free-Kunden, für die er lokal deployt). Solche Tokens sind als „vom Betreuer erzeugt" gekennzeichnet und funktionieren am Deploy-Endpunkt unabhängig vom Plan des Kunden.

1. Token erzeugen #

Dashboard → Konto → „API-Zugang" → „Token erzeugen". Das Token (psk_…) wird nur einmal angezeigt – kopieren und sicher aufbewahren. Es gilt nur für diese Website und lässt sich jederzeit widerrufen. (Betreust du fremde Konten als Partner: „Als Kunde arbeiten" starten, dann dort das Token erzeugen.)

Konto-Token (frisches Konto ohne Website) #

Für den Erst-Import (neues Konto → Website hochladen + veröffentlichen, ohne Dashboard-ZIP-Import) gibt es das Konto-Token: nicht an eine Website gebunden, sondern ans Konto – mit dem Recht, die erste Website anzulegen und danach die Website(s) des Kontos zu aktualisieren. Erzeugt wird es im Admin/Partner-Bereich beim Einrichten des Kontos (auch schon, bevor eine Website existiert). Deployed wird damit auf /api/deploy/new (siehe Erst-Import unten).

2. Deployen (curl) #

# Update-Import der aktiven Website + direkt veröffentlichen:
curl -X POST "https://app.prontosite.io/api/deploy/<site>?publish=1" \
  -H "Authorization: Bearer psk_DEIN_TOKEN" \
  -H "Content-Type: application/zip" \
  --data-binary @meine-website.zip

• <site> = stabile Site-ID (s-…, empfohlen – ändert sich nie) oder active (nimmt die aktive Website des Kontos, robustest bei „ein Konto, eine Website"). Der Slug wird ebenfalls akzeptiert, kann aber veralten (eigene Domain, Umbenennung) → dann klare Fehlermeldung mit Hinweis auf Site-ID/active, kein stiller 404. Die Site-ID steht im Dashboard (Konto → API-Zugang) und im MCP-Snippet.
• ?publish=1 — nach dem Import direkt live schalten. Weglassen = nur importieren (Entwurf), später im Dashboard veröffentlichen.
• ?resetOverlay=1 — bisherige Dashboard-Änderungen (Overlay) verwerfen; der ZIP-Stand ist die Wahrheit (empfohlen, wenn du komplett lokal arbeitest). Ohne den Parameter bleiben auflösbare Dashboard-Änderungen erhalten (Merge, wie im Dashboard-Update-Import).

Erst-Import (Konto-Token → Website anlegen + veröffentlichen) #

Mit einem Konto-Token legst du die erste Website direkt an – der Endpunkt erkennt, dass noch keine Website existiert (oder du gibst explizit /new an):

curl -X POST "https://app.prontosite.io/api/deploy/new?publish=1&slug=meine-firma&name=Meine%20Firma" \
  -H "Authorization: Bearer psk_DEIN_KONTO_TOKEN" \
  -H "Content-Type: application/zip" \
  --data-binary @meine-website.zip

• /new — Website anlegen (statt aktualisieren). Ist das Konto noch leer, genügt auch jeder andere <site>-Wert – ohne Website wird immer angelegt.
• ?slug= — Wunsch-Adresse (<slug>.prontosite.io). Ohne Angabe leiten wir sie aus dem Namen ab.
• ?name= — Anzeigename/Website-Titel. Ohne Angabe aus dem Paket/Konto abgeleitet.
• Rechts-Automatik (Default beim Erst-Import): Impressum + Datenschutz werden automatisch generiert und aktiviert und als eigenständige Seiten /impressum/ + /datenschutz/ mitveröffentlicht – aus den am Konto hinterlegten Firmendaten. Fehlen Firmendaten, wird trotzdem generiert (sichtbare [Angabe fehlt: …]-Marker); die Antwort listet die fehlenden Felder. Hostet die hochgeladene Website eine Rolle bereits selbst (eigene Impressum-/Datenschutz-Seite), lassen wir sie unangetastet. Mit ?legal=0 schaltest du die Automatik ab, mit ?legal=1 erzwingst du sie auch beim Update-Import.
• Cookie-Banner wird nicht erzwungen: es aktiviert sich beim Veröffentlichen automatisch, sobald die Seite einwilligungspflichtige Inhalte hat (Google Analytics/Ads oder eingebettete Fremdinhalte).

3. Antwort (JSON) #

{
  "ok": true,
  "mode": "created",
  "site": "s-abc123", "slug": "meine-firma",
  "pages": { "added": 6, "changed": 0, "removed": 0 },
  "keptOps": 0, "deactivatedOps": 0, "resetOverlay": false,
  "rejectedFiles": [{ "file": "skript.php", "reason": "Server-Code wird nicht übernommen" }],
  "markers": { "widgets": ["google-reviews"], "forms": [] },
  "warnings": ["…"],
  "backup": null,
  "legal": {
    "generated": ["impressum", "datenschutz"],
    "standalonePages": ["/impressum/", "/datenschutz/"],
    "hostedBySite": [],
    "missingCompanyFields": ["Anschrift"],
    "notLinked": ["datenschutz"]
  },
  "published": true, "liveUrl": "https://meine-firma.prontosite.io"
}

So siehst du lokal, was passiert ist: mode (created beim Erst-Import, sonst updated), übernommene/geänderte/entfallene Seiten, abgelehnte Dateien mit Grund, erkannte Marker/Formulare, Warnungen – und ob veröffentlicht wurde. Der Block legal meldet, was die Rechts-Automatik getan hat: generated = erzeugte+aktivierte Rollen (mit standalonePages), hostedBySite = Rollen, die die hochgeladene Website selbst hostet (übersprungen), missingCompanyFields = fehlende Firmendaten (als [Angabe fehlt] live), notLinked = generierte Rechtsseiten, auf die die Website (noch) nicht verlinkt – dann im Footer einen Link ergänzen. Ist die Automatik aus, steht dort "legal": { "disabled": true }.

Weitere Endpunkte (Status, Export, erneut veröffentlichen) #

Neben deploy gibt es drei schlanke Token-Endpunkte (gleiche Auth/Rate-Limit/Audit):

# Status: Plan, Slug, Live-URL, offener Veröffentlichungsbedarf (LESEND)
curl -s "https://app.prontosite.io/api/status/<site>" -H "Authorization: Bearer psk_DEIN_TOKEN"

# Export als ZIP: which=published (Live, Standard) | draft | original (LESEND)
curl -s "https://app.prontosite.io/api/export/<site>?which=published" \
  -H "Authorization: Bearer psk_DEIN_TOKEN" -o website.zip

# Erneut veröffentlichen (ohne ZIP) – z. B. um Plattform-Updates live zu bringen
curl -s -X POST "https://app.prontosite.io/api/publish/<site>" -H "Authorization: Bearer psk_DEIN_TOKEN"

# Alle erreichbaren Sites (Betreuer-Token: alle betreuten Kunden; sonst die eigene)
curl -s "https://app.prontosite.io/api/sites" -H "Authorization: Bearer psk_DEIN_TOKEN"

status liefert u. a. { slug, plan, liveUrl, everPublished, publishNeeded, changes }.

Betreuer-Token (Admin/Partner – alle betreuten Kunden) #

Ein konto-übergreifendes Token für Agenturen/Partner: deckt ALLE betreuten Kunden ab (statt ein Token je Kunde). Erzeugt im Admin/Partner-Bereich (Panel „Betreuer-Token"). <site> = Slug oder stabile Site-ID (kein active – mehrere Konten); GET /api/sites listet alle betreuten Sites. Erst-Import in ein betreutes Konto: POST /api/deploy/new?customer=<konto-id>. Der Zugriff wird bei JEDEM Aufruf serverseitig geprüft (nur betreute Konten; Rollenentzug wirkt sofort), nur Deploy/Status/Export/Veröffentlichen – kein Konto-/ Zahlungszugriff. Optionaler Ablauf (Default 90 Tage) + optionale IP-Bindung; Widerruf sperrt alles auf einmal.

Firmendaten setzen (Company-API) #

Damit die Rechtstext-Automatik beim Deploy ein vollständiges Impressum/Datenschutz erzeugt, kannst du die Firmendaten per Token setzen – konto-weit, mit Teil-Update (nur gesetzte Felder ändern sich):

# Lesen (effektiver Stand + konto-weite Angaben)
curl -s "https://app.prontosite.io/api/company/<site>" -H "Authorization: Bearer psk_DEIN_TOKEN"

# Setzen/ergänzen (JSON) – nur die mitgeschickten Felder werden geändert
curl -X PUT "https://app.prontosite.io/api/company/<site>" \
  -H "Authorization: Bearer psk_DEIN_TOKEN" -H "Content-Type: application/json" \
  --data '{"company":{"name":"Beispiel GmbH","street":"Hauptstr. 1","zip":"50667","city":"Köln","country":"DE","email":"info@beispiel.de","representative":"Max Mustermann","vatId":"DE123456789"}}'

• Felder wie im Dashboard: name, legalForm, representative, street, zip, city, country, email, phone, fax, vatId, registerCourt, registerNumber, kammer, berufsbezeichnung, aufsichtsbehoerde, verantwortlichMStV, berufshaftpflicht, social[{label,href}].
• Standard ist konto-weit (account_company). Für abweichende Daten NUR dieser Website: {"siteOverride":true, "company":{…}} (oder ?scope=site).
• Die Deploy-Antwort meldet unter legal.missingCompanyFields, welche Pflichtangaben noch fehlen.

Anzeige-Optionen der Rechtstexte (Legal-Options) #

Pro Rolle (impressum/datenschutz) lassen sich die Anzeige-Optionen der Rechtstext-Widgets per Token setzen – Teil-Update, nur mitgeschickte Booleans wirken:

curl -X PUT "https://app.prontosite.io/api/legal-options/<site>" \
  -H "Authorization: Bearer psk_DEIN_TOKEN" -H "Content-Type: application/json" \
  --data '{"impressum":{"showTitle":false},"datenschutz":{"showDate":false,"draftNotice":true}}'

• showTitle – Überschrift (H1) des Rechtstextes anzeigen (Default an).
• showDate – „Stand"-Datum anzeigen (Default an; i. d. R. nur Datenschutz).
• draftNotice – Entwurfs-Hinweis in der veröffentlichten Seite anzeigen (Default an). false blendet ihn live aus – der Vorgang wird protokolliert; im Editor bleibt der Hinweis sichtbar.

GET /api/legal-options/<site> liefert den aktuellen Stand beider Rollen.

Per KI-Assistent (MCP) #

Dieselben Aktionen gibt es als MCP-Server für Claude Desktop u. a. – „per Terminal (curl)" und „per KI-Assistent (MCP)" stehen bewusst nebeneinander; die HTTP-API bleibt der primäre, dokumentierte Weg, der MCP-Server ist ein zusätzlicher Client darauf (dünner Wrapper, keine eigene Logik, kein Ersatz).

Tools: site_status, site_export, site_deploy (optional company:{…} im selben Aufruf), site_publish, site_company_get, site_company_set, site_legal_options. Einrichtung + Claude-Desktop-Config-Snippet: siehe KI-Assistent (MCP). Token/Site kommen aus lokaler Config (PRONTOSITE_TOKEN/PRONTOSITE_SITE oder ~/.prontosite.json), nie aus dem Chat. Die schreibenden Tools (site_deploy, site_publish) sind so beschrieben, dass der Assistent vor dem Ausführen rückfragt.

Grenzen & Sicherheit #

• Es gelten dieselben Grenzen wie im Dashboard-Import: max. 100 MB ZIP, nur .zip, Server-Code (php/asp …) wird nicht übernommen, eigenes JavaScript wird byte-treu übernommen und ausgeliefert.
• Rate-Limit: einige Deploys pro Stunde je Token.
• Publish unterliegt den normalen Grenzen (bestätigte E-Mail, KI-/Speicher-Kontingent des Plans).
• Jeder Deploy wird protokolliert. Ein widerrufenes Token wird sofort mit 401 abgelehnt.

Fehlercodes #