Diverse operazioni che prima richiedevano di accedere a MyKinsta ora possono essere gestite tramite l’API di Kinsta.

Puoi scegliere come configurare un nuovo dominio, gestire l’opzione “Forza HTTPS”, eseguire operazioni di ricerca e sostituzione su un database, restringere i log del sito a un periodo di tempo specifico e verificare se è disponibile un backup scaricabile prima di richiederne uno.

Aggiungi domini con maggiore controllo

L’endpoint esistente per aggiungere un nuovo dominio ora supporta due campi opzionali: add_with_www_subdomain e setup_type.

Usa add_with_www_subdomain per aggiungere la versione www di un dominio nella stessa richiesta del dominio principale. Questo campo non può essere abilitato quando is_wildcardless è impostato su true.

Il campo setup_type permette di scegliere tra:

  • quick, che è il metodo di configurazione predefinito.
  • avoid_downtime, per i flussi di lavoro in cui il dominio deve essere preparato prima che il traffico venga reindirizzato.

Ad esempio, la seguente richiesta aggiunge example.com e il suo sottodominio www utilizzando l’opzione di configurazione pensata per evitare tempi di inattività:

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

Quando la richiesta viene accettata, l’API restituisce una risposta 202 con un ID operazione che puoi usare per monitorarne lo stato:

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

Puoi trovare tutti i campi supportati e i dettagli della risposta nella documentazione dell’API.

Controlla e modifica “Forza HTTPS”

Due nuovi endpoint offrono l’accesso programmatico allo strumento “Forza HTTPS” di Kinsta. Puoi recuperare l’impostazione attuale di un ambiente e aggiornarla senza aprire MyKinsta.

Per controllare lo stato attuale, invia una richiesta GET:

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

La risposta restituisce uno di questi valori:

  • ENABLED_FOR_ALL
  • ENABLED_REDIRECT_TO_PRIMARY
  • DISABLED

Ad esempio:

{
  "force_https_status": "ENABLED_REDIRECT_TO_PRIMARY"
}

Per modificare l’impostazione, invia una richiesta POST con uno dei valori supportati:

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 avvia l’aggiornamento e restituisce un ID operazione:

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

Questo significa che la configurazione del dominio e dell’HTTPS può ora far parte dello stesso flusso di lavoro di provisioning o migrazione.

Esegui Cerca e Sostituisci tramite l’API

Il nuovo endpoint di ricerca e sostituzione aggiunge un altro strumento familiare di MyKinsta all’API di Kinsta.

Puoi cercare un valore nel database di WordPress, sostituire tutte le occorrenze e svuotare le cache del sito al termine dell’operazione. Tra gli scenari tipici ci sono la sostituzione di un vecchio nome di dominio dopo una migrazione o la modifica degli URL da HTTP a HTTPS.

Il campo perform_replacement determina se la richiesta si limita a cercare le corrispondenze o se le sostituisce anche.

Ecco un esempio che sostituisce un vecchio nome di dominio con uno nuovo:

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

Quando l’azione parte con successo, la risposta include un ID operazione:

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

Come con lo strumento “Cerca e sostituisci” in MyKinsta, Kinsta crea un backup generato dal sistema prima di eseguire la sostituzione.

“Cerca e sostituisci” distingue tra maiuscole e minuscole, quindi i valori di ricerca e sostituzione vanno controllati attentamente prima di inviare la richiesta.

Consultare un periodo specifico dei log

L’endpoint “get site logs” ora supporta i parametri di query opzionali search, from e to.

Questo permette di restringere i risultati dei log a un periodo di tempo specifico, invece di recuperare un ampio insieme di voci recenti. Puoi applicare i filtri quando richiedi i log degli errori, i log di accesso o i log delle prestazioni della cache di Kinsta.

Ad esempio, la seguente richiesta cerca nei log degli errori PHP Fatal error all’interno di un periodo specifico:

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

Le voci di log corrispondenti vengono visualizzate nel campo logs:

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

Questo è utile quando sai più o meno quando è iniziato un problema o vuoi controllare i log relativi a una distribuzione senza dover recuperare un grande blocco di voci non pertinenti.

Kinsta conserva i log del sito per un massimo di quattro giorni, quindi l’intervallo di date richiesto deve rientrare nel periodo di conservazione disponibile. Scopri di più nella documentazione dell’API.

Verifica quando è disponibile un backup scaricabile

È possibile generare un backup scaricabile una volta alla settimana. Questo nuovo endpoint “next-downloadable-backup-available” ti permette ora di verificare se ne è disponibile un altro prima di avviare l’operazione.

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

Se non è ancora possibile creare un altro backup scaricabile, la risposta include l’orario in cui sarà disponibile il prossimo:

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

Anche l’endpoint esistente per generare un backup scaricabile (downloadable-backups) è stato aggiornato. Ora restituisce un errore quando viene richiesto un altro backup prima dell’ora di reset.

Quando una richiesta viene accettata, la risposta include un ID operazione:

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

Esempio di risposta:

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

Puoi trovare tutti i dettagli nella documentazione API per verificare la disponibilità dei backup e crearne uno scaricabile.

Integra più flussi di lavoro di MyKinsta nei tuoi strumenti

Queste versioni ampliano l’accesso programmatico a diversi flussi di lavoro quotidiani di MyKinsta.

Insieme, queste novità rendono più facile gestire gli ambienti WordPress in modo coerente tra dashboard interne, script di provisioning, flussi di lavoro di distribuzione e altre automazioni create con l’API di Kinsta.