Nous avons déployé un nouvel ensemble de points de terminaison d’API et d’améliorations visant à donner aux développeurs WordPress plus de contrôle sur les opérations du site, la configuration DNS et les paramètres des ressources.

Vous pouvez maintenant automatiser des tâches allant de la réinitialisation des sites WordPress à la gestion des enregistrements de vérification de domaine et des entrées DNS, en particulier à grande échelle.

Voici les nouveautés :

Réinitialiser un site

Comme pour le tableau de bord MyKinsta, vous pouvez maintenant réinitialiser un site WordPress en utilisant le nouveau point de terminaison de l’API /reset-site de l’API. Cette action réinitialise le système de fichiers et la base de données du site, le ramenant à une installation WordPress propre.

C’est idéal pour les configurations par script, le provisionnement de modèles, ou pour repartir rapidement à zéro pendant le développement.

Pour l’utiliser, envoyez une requête à POST avec l’identifiant du site et votre mot de passe administrateur :

curl -i -X POST \
  'https://api.kinsta.com/v2/sites/{site_id}/reset-site' \ 
  -H 'Authorization: Bearer ' \
  -H 'Content-Type: application/json' \
  -d '{
    "admin_password": "your-admin-password"
  }'

Récupérer les enregistrements de vérification et de pointage pour un domaine

Nous avons également introduit le point de terminaison /verification-records qui vous permet de récupérer les enregistrements de vérification et de pointage pour n’importe quel domaine connecté à un environnement WordPress.

Ceci est utile pour configurer des domaines personnalisés et confirmer qu’ils pointent correctement. C’est également utile si vous souhaitez automatiser la vérification des domaines dans le cadre de flux de travail CI/CD ou de provisionnement.

Voici un exemple de requête :

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/domains/{site_domain_id}/verification-records' \
  -H 'Authorization: Bearer '

La réponse comprend des enregistrements DNS tels que les entrées CNAME ou TXT nécessaires à la validation du domaine et à la configuration du réseau périphérique :

{
  "site_domain": {
    "verification_records": [
      {
        "name": "_acme-challenge.staging.example-site.io",
        "value": "staging.example-site.io.kinstavalidation.app",
        "type": "CNAME"
      }
    ],
    "pointing_records": [
      {
        "name": "staging.example-site.io",
        "value": "192.0.2.10",
        "type": "A"
      },
      {
        "name": "www",
        "value": "staging.example-site.io",
        "type": "CNAME"
      }
    ]
  }
}

Gestion programmatique des enregistrements DNS

Vous pouvez maintenant gérer les domaines et les enregistrements DNS de manière programmatique en utilisant l’API Kinsta (similaire à la fonctionnalité disponible dans MyKinsta sous Kinsta’s DNS).

Cela inclut :

Ce support API reflète ce que vous pouvez faire dans MyKinsta lorsque vous gérez des zones liées au DNS de Kinsta, alimenté par Amazon Route53.

Par exemple. Supposons que vous souhaitiez ajouter un enregistrement A pour un sous-domaine :

curl -X POST \
  'https://api.kinsta.com/v2/domains/{domain_id}/dns-records' \
  -H 'Authorization: Bearer ' \
  -H 'Content-Type: application/json' \
  -d '{
    "type": "A",
    "name": "staging.mydomain.com",
    "ttl": 3600,
    "resource_records": [
      { "value": "1.1.1.1" }
    ]
  }'

Ceci est utile pour provisionner des domaines dynamiquement ou synchroniser les changements DNS depuis votre pipeline CI/CD, en particulier pour les agences multisites ou les flux de travail à fort contenu de mise en scène.

Pour les types d’enregistrements supportés et le comportement DNS, référez-vous à la documentation DNS de Kinsta.

Définir l’allocation des threads PHP

Le module de performance PHP est l’un des modules les plus utilisés chez Kinsta, car il aide les sites à gérer plus de trafic et de traitements lourds sans transpirer.

Il était logique d’apporter ce contrôle dans l’API, et donc plus tôt cette année, nous avons introduit deux points d’extrémité pour gérer la performance PHP par programme :

Ces points de terminaison acceptaient à l’origine worker_number et worker_memory, mais en accord avec notre changement de « workers PHP » à « threads » (qui reflète mieux la façon dont PHP fonctionne réellement), nous avons maintenant déprécié ces anciens champs.

Champs obsolètes.
Champs obsolètes.

D’ici la fin du mois d’août 2025, seuls thread_count et thread_memory seront supportés. Si vous utilisez déjà ces points de terminaison, il est temps de mettre à jour vos requêtes.

Voici à quoi ressemble une requête de configuration de thread utilisant les champs mis à jour :

curl -i -X POST \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/change-environment-php-allocation' \
  -H 'Authorization: Bearer ' \
  -H 'Content-Type: application/json' \
  -d '{
    "thread_count": 2,
    "thread_memory": 256
  }'

Ce qui précède définit deux threads PHP pour cet environnement, chacun disposant de 256 Mo de mémoire. Cela correspond au même contrôle que vous trouverez dans MyKinsta.

Les listes d’environnements affichent désormais la version de WordPress

Lorsque vous gérez plusieurs sites, il est utile de savoir exactement quelle version de WordPress tourne dans chaque environnement, en particulier si votre équipe a des calendriers de mise à jour différents selon les clients ou les étapes.

Nous avons ajouté un nouveau champ wordpress_version à ces points de terminaison :

Désormais, lorsque vous récupérez des données sur l’environnement, la version de WordPress est incluse. Il est ainsi plus facile de repérer les installations obsolètes ou de confirmer que les mises à jour ont été appliquées avec succès sans avoir à se connecter manuellement à chaque site.

Voici un exemple de réponse :

{
  "site": {
    "environments": [
      {
        "id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
        "name": "live",
        "display_name": "Live",
        "wordpress_version": "6.3.1",
        "is_premium": false,
        "is_additional_sftp_accounts_enabled": false,
        ...
      }
    ]
  }
}

Obtenir une liste des régions disponibles

Supposons que vous ayez besoin de créer de nouveaux environnements dans un lieu spécifique. Avec le nouveau point de terminaison /available-regions vous pouvez désormais récupérer la liste des régions disponibles liées à votre entreprise.

Cela vous aide à confirmer de manière programmatique les emplacements des centres de données disponibles pour les déploiements et s’avère utile si vous gérez plusieurs clients ou si vous vous étendez sur différentes régions.

Voici un exemple de réponse :

{
  "company": {
    "available_regions": [
      {
        "name": "Dallas US (us-south1)",
        "region": "us-south1"
      }
    ]
  }
}

Plus de flexibilité pour vos flux de travail

Ce lot de mises à jour vous donne plus de contrôle programmatique sur les environnements, les domaines, les enregistrements DNS, les performances PHP et les déploiements régionaux.

Qu’il s’agisse de régler les threads et la mémoire, de gérer les domaines à grande échelle ou de synchroniser les versions de WordPress entre les sites, l’API Kinsta continue de se développer en tenant compte des équipes modernes.

Vous avez besoin d’une preuve de son évolutivité ? Nous avons récemment publié une étude de cas sur la façon dont Sod gère plus de 400 sites avec une automatisation personnalisée construite sur l’API Kinsta.