Plusieurs tâches qui nécessitaient auparavant de se rendre sur MyKinsta peuvent désormais être effectuées via l’API Kinsta.

Vous pouvez choisir la manière dont un nouveau domaine est configuré, gérer l’option « Forcer HTTPS », effectuer une recherche et un remplacement dans une base de données, filtrer les journaux du site sur une période spécifique et vérifier si une sauvegarde téléchargeable est disponible avant d’en demander une.

Ajouter des domaines avec davantage de contrôle

Le point de terminaison existant permettant d’ajouter un nouveau domaine de site prend désormais en charge deux champs facultatifs : « add_with_www_subdomain » et « setup_type ».

Utilisez « add_with_www_subdomain » pour ajouter la version www d’un domaine dans la même requête que le domaine racine. Ce champ ne peut pas être activé lorsque « is_wildcardless » est défini sur « true ».

Le champ « setup_type » vous permet de choisir entre :

  • quick, qui correspond à la méthode de configuration par défaut.
  • avoid_downtime, pour les workflows dans lesquels le domaine doit être préparé avant que le trafic ne soit basculé.

Par exemple, la requête suivante ajoute example.com et son sous-domaine www à l’aide de l’option de configuration conçue pour éviter toute interruption de service :

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"
  }'

Lorsque la requête est acceptée, l’API renvoie une réponse 202 contenant un identifiant d’opération que vous pouvez utiliser pour suivre sa progression :

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

Vous trouverez tous les champs pris en charge et les détails de la réponse dans la documentation de l’API.

Vérifier et modifier « Forcer HTTPS »

Deux nouveaux points de terminaison permettent d’accéder par programmation à l’outil « Force HTTPS » de Kinsta. Vous pouvez récupérer le paramètre actuel d’un environnement et le mettre à jour sans ouvrir MyKinsta.

Pour vérifier l’état actuel, envoyez une requête GET :

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

La réponse renvoie l’une des valeurs suivantes :

  • ENABLED_FOR_ALL
  • ENABLED_REDIRECT_TO_PRIMARY
  • DISABLED

Par exemple :

{
  "force_https_status": "ENABLED_REDIRECT_TO_PRIMARY"
}

Pour modifier le paramètre, envoyez une requête POST avec l’une des valeurs prises en charge :

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"
  }'

L’API lance la mise à jour et renvoie un identifiant d’opération :

{
  "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
}

Cela signifie que la configuration du domaine et du protocole HTTPS peut désormais s’intégrer au même workflow de provisionnement ou de migration.

Effectuer une recherche et un remplacement via l’API

Le nouveau point de terminaison de recherche et de remplacement ajoute un autre outil familier de MyKinsta à l’API Kinsta.

Vous pouvez rechercher une valeur dans la base de données WordPress, remplacer toutes les occurrences et vider les caches du site après l’opération. Parmi les scénarios courants, on peut citer le remplacement d’un ancien nom de domaine après une migration ou la conversion des URL de HTTP vers HTTPS.

Le champ « perform_replacement » permet de déterminer si la requête se contente de rechercher les occurrences ou si elle les remplace également.

Voici un exemple illustrant le remplacement d’un ancien nom de domaine par un nouveau :

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
  }'

Lorsque l’action démarre avec succès, la réponse comprend un identifiant d’opération :

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

Comme pour l’outil « Recherche et remplacement » de MyKinsta, Kinsta crée une sauvegarde générée par le système avant d’exécuter le remplacement.

La fonction « Recherche et remplacement » est sensible à la casse ; il convient donc de vérifier attentivement les valeurs de recherche et de remplacement avant d’envoyer la requête.

Recherche dans les journaux sur une période donnée

Le point de terminaison « get site logs » prend désormais en charge les paramètres de requête facultatifs « search », « from » et « to ».

Cela vous permet de limiter les résultats des journaux à une période spécifique plutôt que de récupérer un ensemble étendu d’entrées récentes. Vous pouvez appliquer ces filtres lorsque vous demandez des journaux d’erreurs, des journaux d’accès ou des journaux de performances du cache Kinsta.

Par exemple, la requête suivante recherche dans les journaux d’erreurs la chaîne « PHP Fatal error » au cours d’une période spécifique :

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

Les entrées de journal correspondantes s’affichent dans le champ « logs » :

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

Cette fonctionnalité est utile lorsque vous savez approximativement quand un problème a commencé ou que vous souhaitez consulter les journaux relatifs à un déploiement sans récupérer un grand nombre d’entrées non pertinentes.

Kinsta conserve les journaux des sites pendant quatre jours maximum ; la plage de dates demandée doit donc se situer dans la période de conservation disponible. Pour en savoir plus, consultez la documentation de l’API.

Vérifier la disponibilité d’une sauvegarde téléchargeable

Une sauvegarde téléchargeable peut être générée une fois par semaine. Ce nouveau point de terminaison « next-downloadable-backup-available » vous permet désormais de vérifier si une autre sauvegarde est disponible avant de lancer l’action.

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

Si une autre sauvegarde téléchargeable ne peut pas encore être créée, la réponse indique la prochaine heure de disponibilité :

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

Le point de terminaison existant permettant de générer une sauvegarde téléchargeable (downloadable-backups) a également été mis à jour. Il renvoie désormais une erreur lorsqu’une autre sauvegarde est demandée avant l’heure de réinitialisation.

Lorsqu’une demande est acceptée, la réponse inclut un identifiant d’opération :

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

Exemple de réponse :

{
  "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
}

Vous trouverez tous les détails dans la documentation de l’API concernant la vérification de la disponibilité des sauvegardes et la création d’une sauvegarde téléchargeable.

Intégrez davantage de workflows MyKinsta à vos propres outils

Ces mises à jour étendent l’accès programmatique à plusieurs workflows MyKinsta courants.

Ensemble, ces ajouts facilitent la gestion cohérente des environnements WordPress à travers les tableaux de bord internes, les scripts de provisionnement, les workflows de déploiement et d’autres automatisations développées à l’aide de l’API Kinsta.