Abbiamo lanciato una nuova serie di endpoint API e di miglioramenti per dare agli sviluppatori di WordPress un maggiore controllo sulle operazioni del sito, sulla configurazione dei DNS e sulla configurazione delle risorse.

Ora è possibile automatizzare attività che vanno dal ripristino dei siti WordPress alla gestione dei record di verifica del dominio e delle voci del DNS, soprattutto in scala.

Ecco le novità:

Reset di un sito

Come per la dashboard di MyKinsta, ora è possibile resettare un sito WordPress utilizzando il nuovo endpoint dell’API /reset-site. Questa azione ripristina il file system e il database del sito, riportandolo a un’installazione pulita di WordPress.

È l’ideale per le configurazioni con script, per il provisioning di modelli o per ripartire rapidamente da zero durante lo sviluppo.

Per utilizzarla, basta inviare una richiesta POST con l’ID del sito e la password di amministratore:

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

Recuperare i record di verifica e di puntamento per un dominio

Abbiamo introdotto anche l’endpoint /verification-records. Questo permette di recuperare i record di verifica e di puntamento per qualsiasi dominio collegato a un ambiente WordPress.

Questo è utile quando si configurano domini personalizzati e si verifica che stiano puntando correttamente. È utile anche se si vuole automatizzare la verifica dei domini nell’ambito di workflow CI/CD o di provisioning.

Ecco un esempio di richiesta:

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

La risposta fornisce i record relativi al DNS, come le voci CNAME o TXT, necessarie per la convalida del dominio e la configurazione della rete edge:

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

Gestire i record DNS in modo programmatico

Ora è possibile gestire in modo programmatico i domini e i record DNS utilizzando l’API di Kinsta (in modo simile alla funzionalità disponibile in MyKinsta alla voce Kinsta DNS).

Questo comprende:

Questa novità dell’API rispecchia quello che è possibile fare in MyKinsta quando si gestiscono le zone collegate al DNS di Kinsta, gestito da Amazon Route53.

Facciamo un esempio. Supponiamo di voler aggiungere un record A per un sottodominio:

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

Questo è utile per il provisioning dinamico dei domini o per la sincronizzazione delle modifiche DNS dalla pipeline CI/CD, in particolare per le agenzie del multisito o per i workflow che richiedono un’intensa attività di staging.

Per i tipi di record supportati e il comportamento del DNS, si veda la documentazione sui DNS di Kinsta.

Impostare l’allocazione dei thread PHP

L’add-on per le prestazioni di PHP è uno dei componenti aggiuntivi più utilizzati su Kinsta in quanto permette ai siti di gestire maggior traffico e elaborazione intensa senza problemi.

Era logico portare questo controllo all’interno dell’API e così, all’inizio di quest’anno, abbiamo introdotto due endpoint per gestire le prestazioni di PHP in modo programmatico:

In origine questi endpoint accettavano worker_number e worker_memory, ma in linea con il passaggio da “PHP workers” a “threads” (che riflette meglio il funzionamento effettivo di PHP), abbiamo deprecato questi vecchi campi.

Campi deprecati.
Campi deprecati.

Entro la fine di agosto 2025, saranno supportati solo thread_count e thread_memory. Se si utilizzano già questi endpoint, è opportuno aggiornare le richieste.

Ecco come appare una richiesta di configurazione di un thread che utilizza i campi aggiornati:

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

In questo modo vengono impostati due thread PHP per quell’ambiente, ciascuno con 256 MB di memoria. Questo corrisponde allo stesso controllo che si trova in MyKinsta.

Gli elenchi degli ambienti ora mostrano la versione di WordPress

Quando si gestiscono più siti, è utile sapere esattamente quale versione di WordPress è in esecuzione in ogni ambiente, soprattutto se il team ha programmi di aggiornamento diversi tra i vari clienti o le varie fasi.

Abbiamo aggiunto un nuovo campo wordpress_version a questi endpoint:

Ora, quando si recuperano i dati dell’ambiente, viene inclusa la versione di WordPress. In questo modo è più facile individuare installazioni obsolete o avere conferma che gli aggiornamenti sono stati applicati correttamente senza dover accedere manualmente a ogni sito.

Ecco un esempio di risposta:

{
  "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,
        ...
      }
    ]
  }
}

Ottenere un elenco delle regioni disponibili

Supponiamo di dover creare nuovi ambienti in un luogo specifico. Con il nuovo endpoint /available-regions è possibile recuperare l’elenco delle regioni disponibili legate all’azienda.

Questo permette di verificare in modo programmatico quali sono le sedi dei data center disponibili per le implementazioni ed è utile se si gestiscono più clienti o se si sta scalando in diverse regioni.

Ecco un esempio di risposta:

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

Workflow più flessibili

Questa serie di aggiornamenti offre un maggiore controllo programmatico su ambienti, domini, record DNS, prestazioni PHP e distribuzioni regionali.

Regolazione dei thread e della memoria, gestione di domini su scala o sincronizzazione delle versioni di WordPress tra i siti: l’API di Kinsta continua a crescere pensando ai team all’avanguardia.

Hai bisogno di una prova della sua scalabilità? Di recente abbiamo pubblicato un caso di studio su come Sod gestisce oltre 400 siti con un’automazione personalizzata basata sull’API Kinsta.