Mehrere Aufgaben, für die du bisher MyKinsta aufrufen musstest, kannst du jetzt über die Kinsta-API erledigen.

Du kannst festlegen, wie eine neue Domain eingerichtet wird, „Force HTTPS“ verwalten, Such- und Ersetzungsvorgänge in einer Datenbank durchführen, Website-Protokolle auf einen bestimmten Zeitraum eingrenzen und prüfen, ob ein herunterladbares Backup verfügbar ist, bevor du eines anforderst.

Domains mit mehr Kontrolle hinzufügen

Der bestehende Endpunkt zum Hinzufügen einer neuen Website-Domain unterstützt nun zwei optionale Felder: add_with_www_subdomain und setup_type.

Verwende add_with_www_subdomain, um die www-Version einer Domain in derselben Anfrage wie die Root-Domain hinzuzufügen. Dieses Feld kann nicht aktiviert werden, wenn is_wildcardless auf true gesetzt ist.

Über das Feld setup_type kannst du wählen zwischen:

  • quick, was die Standard-Einrichtungsmethode ist.
  • avoid_downtime, für Workflows, bei denen die Domain vorbereitet werden muss, bevor der Datenverkehr umgeleitet wird.

Die folgende Anfrage fügt beispielsweise example.com und dessen Subdomain www mithilfe der Einrichtungsoption hinzu, die darauf ausgelegt ist, Ausfallzeiten zu vermeiden:

curl --request POST \
  --url https://api.kinsta.com/v2/sites/environments/{env_id}/domains \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  --header 'Content-Type: application/json' \
  --data '{
    "domain_name": "example.com",
    "is_wildcardless": false,
    "add_with_www_subdomain": true,
    "setup_type": "avoid_downtime"
  }'

Wenn die Anfrage akzeptiert wird, gibt die API eine Antwort unter 202 mit einer Vorgangs-ID zurück, mit der du den Fortschritt verfolgen kannst:

{
  "operation_id": "sites:add-domain-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "message": "Adding site domain in progress",
  "status": 202
}

Alle unterstützten Felder und Details zur Antwort findest du in der API-Dokumentation.

„Force HTTPS“ prüfen und ändern

Zwei neue Endpunkte bieten programmatischen Zugriff auf das „Force HTTPS“-Tool von Kinsta. Du kannst die aktuelle Einstellung für eine Umgebung abrufen und aktualisieren, ohne MyKinsta zu öffnen.

Um den aktuellen Status zu überprüfen, sende eine GET-Anfrage:

curl --request GET \
  --url https://api.kinsta.com/v2/sites/environments/{env_id}/force-https-status \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Die Antwort gibt einen der folgenden Werte zurück:

  • ENABLED_FOR_ALL
  • ENABLED_REDIRECT_TO_PRIMARY
  • DISABLED

Beispiel:

{
  "force_https_status": "ENABLED_REDIRECT_TO_PRIMARY"
}

Um die Einstellung zu ändern, sende eine POST-Anfrage mit einem der unterstützten Werte:

curl --request POST \
  --url https://api.kinsta.com/v2/sites/environments/{env_id}/force-https-status \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  --header 'Content-Type: application/json' \
  --data '{
    "type": "ENABLED_REDIRECT_TO_PRIMARY"
  }'

Die API startet die Aktualisierung und gibt eine Vorgangs-ID zurück:

{
  "operation_id": "force-https:update-status-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "message": "Updating Force HTTPS status in progress. Use the operation_id to check the status.",
  "status": 202
}

Das bedeutet, dass die Einrichtung von Domain und HTTPS nun Teil desselben Bereitstellungs- oder Migrations-Workflows sein kann.

Suchen und Ersetzen über die API ausführen

Der neue Endpunkt zum Suchen und Ersetzen erweitert die Kinsta-API um ein weiteres bekanntes MyKinsta-Tool.

Du kannst die WordPress-Datenbank nach einem Wert durchsuchen, alle Treffer ersetzen und nach dem Vorgang die Caches der Seiten leeren. Typische Anwendungsfälle sind das Ersetzen eines alten Domainnamens nach einer Migration oder die Umstellung von HTTP- auf HTTPS-URLs.

Das Feld perform_replacement legt fest, ob die Anfrage nur nach Übereinstimmungen sucht oder diese auch ersetzt.

Hier ist ein Beispiel, bei dem ein alter Domainname durch einen neuen ersetzt wird:

curl --request POST \
  --url https://api.kinsta.com/v2/sites/tools/search-and-replace \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>' \
  --header 'Content-Type: application/json' \
  --data '{
    "environment_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
    "search": "old-domain.com",
    "replace": "new-domain.com",
    "perform_replacement": true,
    "is_clear_cache": true
  }'

Wenn der Vorgang erfolgreich gestartet wird, enthält die Antwort eine Vorgangs-ID:

{
  "operation_id": "environments:search-and-replace-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "message": "Search and replace in progress",
  "status": 202
}

Genau wie beim „Suchen und Ersetzen“-Tool in MyKinsta erstellt Kinsta vor der Durchführung des Ersetzungsvorgangs ein systemgeneriertes Backup.

Bei „Suchen und Ersetzen“ wird die Groß-/Kleinschreibung beachtet, daher solltest du die Such- und Ersetzungswerte vor dem Absenden der Anfrage sorgfältig überprüfen.

Suche nach Protokollen innerhalb eines bestimmten Zeitraums

Der Endpunkt „get site logs“ unterstützt nun die optionalen Abfrageparameter search, from und to.

Damit kannst du die Protokollergebnisse auf einen bestimmten Zeitraum eingrenzen, anstatt eine große Menge aktueller Einträge abzurufen. Du kannst die Filter anwenden, wenn du Fehlerprotokolle, Zugriffsprotokolle oder Kinsta-Cache-Leistungsprotokolle abfragst.

Beispielsweise sucht die folgende Anfrage in den Fehlerprotokollen nach PHP Fatal error innerhalb eines bestimmten Zeitraums:

curl --request GET \
  --url 'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=error&lines=1000&search=PHP%20Fatal%20error&from=2026-07-23T00%3A00%3A00.000Z&to=2026-07-24T00%3A00%3A00.000Z' \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Die passenden Protokolleinträge werden im Feld logs angezeigt:

{
  "environment": {
    "container_info": {
      "logs": "Matching log entries..."
    }
  }
}

Das ist nützlich, wenn du ungefähr weißt, wann ein Problem begonnen hat, oder wenn du die Protokolle rund um eine Bereitstellung überprüfen möchtest, ohne einen großen Block irrelevanter Einträge abzurufen.

Kinsta speichert Website-Protokolle bis zu vier Tage lang, daher muss der angeforderte Datumsbereich innerhalb des verfügbaren Aufbewahrungszeitraums liegen. Mehr dazu findest du in der API-Dokumentation.

Prüfen, ob ein herunterladbares Backup verfügbar ist

Ein herunterladbares Backup kann einmal pro Woche erstellt werden. Mit diesem neuen Endpunkt „next-downloadable-backup-available“ kannst du nun vor dem Starten der Aktion prüfen, ob bereits ein neues Backup verfügbar ist.

curl --request GET \
  --url https://api.kinsta.com/v2/sites/environments/{env_id}/next-downloadable-backup-available \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Wenn noch kein weiteres herunterladbares Backup erstellt werden kann, enthält die Antwort den nächstmöglichen Zeitpunkt:

{
  "is_backup_available": false,
  "reset_at": "10/10/2026, 06:16 AM UTC"
}

Der bestehende Endpunkt zum Erstellen eines herunterladbaren Backups (downloadable-backups) wurde ebenfalls aktualisiert. Er gibt nun einen Fehler zurück, wenn ein weiteres Backup vor dem Rücksetzzeitpunkt angefordert wird.

Wenn eine Anfrage angenommen wird, enthält die Antwort eine Vorgangs-ID:

curl --request POST \
  --url https://api.kinsta.com/v2/sites/environments/{env_id}/downloadable-backups \
  --header 'Authorization: Bearer <YOUR_TOKEN_HERE>'

Beispielantwort:

{
  "operation_id": "start-downloadable-backup-generation:update-status-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "message": "Starting downloadable backup generation. Use the operation_id to check the status.",
  "status": 202
}

Ausführliche Informationen findest du in der API-Dokumentation zur Überprüfung der Backup-Verfügbarkeit und zum Erstellen eines herunterladbaren Backups.

Integriere mehr MyKinsta-Workflows in deine eigenen Tools

Diese Releases erweitern den programmatischen Zugriff auf mehrere alltägliche MyKinsta-Workflows.

Zusammen erleichtern diese Ergänzungen die einheitliche Verwaltung von WordPress-Umgebungen über interne Dashboards, Provisioning-Skripte, Bereitstellungs-Workflows und andere mit der Kinsta-API erstellte Automatisierungen hinweg.