Verschillende taken waarvoor je voorheen naar MyKinsta moest, handel je nu af via de Kinsta API.

Je kiest zelf hoe een nieuw domein wordt ingesteld, je beheert Force HTTPS, je voert zoeken en vervangen uit in een database, je beperkt sitelogs tot een specifieke periode en je controleert of er een downloadbare backup beschikbaar is voordat je er een aanvraagt.

Domeinen toevoegen met meer controle

Het bestaande endpoint voor het toevoegen van een nieuw sitedomein ondersteunt nu twee optionele velden: add_with_www_subdomain en setup_type.

Gebruik add_with_www_subdomain om de www-versie van een domein toe te voegen in hetzelfde verzoek als het hoofddomein. Dit veld kun je niet inschakelen als is_wildcardless op true staat.

Met het veld setup_type kies je tussen:

  • quick, de standaard configuratiemethode.
  • avoid_downtime, voor workflows waarbij het domein klaargezet moet worden voordat je het verkeer omschakelt.

Het volgende verzoek voegt bijvoorbeeld example.com en het subdomein www toe, met de configuratieoptie die downtime voorkomt:

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

Zodra het verzoek is geaccepteerd, geeft de API een 202-antwoord terug met een operation ID waarmee je de voortgang volgt:

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

Alle ondersteunde velden en de details over het antwoord vind je in de API-documentatie.

Forceren HTTPS controleren en wijzigen

Twee nieuwe endpoints geven je programmatische toegang tot de Forceren HTTPS-tool van Kinsta. Je haalt de huidige instelling van een omgeving op en werkt die bij zonder MyKinsta te openen.

Om de huidige status te controleren, stuur je een GET-verzoek:

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

Het antwoord geeft een van deze waarden terug:

  • ENABLED_FOR_ALL
  • ENABLED_REDIRECT_TO_PRIMARY
  • DISABLED

Bijvoorbeeld:

{
  "force_https_status": "ENABLED_REDIRECT_TO_PRIMARY"
}

Om de instelling te wijzigen, stuur je een POST-verzoek met een van de ondersteunde waarden:

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

De API start de update en geeft een operation ID terug:

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

Daardoor kun je het instellen van domeinen en HTTPS onderbrengen in dezelfde provisioning- of migratieworkflow.

Zoeken en vervangen via de API

Het nieuwe endpoint voor zoeken en vervangen voegt weer een bekende MyKinsta-tool toe aan de Kinsta API.

Je zoekt in de WordPress database naar een waarde, vervangt alle overeenkomsten en leegt na afloop de caches van de site. Denk hierbij aan het vervangen van een oude domeinnaam na een migratie, of het omzetten van URL’s van HTTP naar HTTPS.

Het veld perform_replacement bepaalt of het verzoek alleen naar overeenkomsten zoekt of ze ook vervangt.

Hier is een voorbeeld waarin een oude domeinnaam wordt vervangen door een nieuwe:

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

Als de actie succesvol start, bevat het antwoord een operation ID:

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

Net als bij de tool Zoeken en vervangen in MyKinsta maakt Kinsta eerst een door het systeem gegenereerde backup voordat de vervanging wordt uitgevoerd.

Zoeken en vervangen is hoofdlettergevoelig, dus controleer je zoek- en vervangwaarden zorgvuldig voordat je het verzoek verstuurt.

Zoeklogboeken binnen een bepaalde periode

Het get site logs-endpoint ondersteunt nu de optionele queryparameters search, from en to.

Daarmee beperk je de logresultaten tot een specifieke periode, in plaats van een lange reeks recente regels op te halen. Je past de filters toe op foutlogs, toegangslogs en Kinsta-cacheprestatielogs.

Het volgende verzoek zoekt bijvoorbeeld in de foutlogs naar PHP Fatal error binnen een specifieke periode:

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

De overeenkomende logregels staan in het veld logs:

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

Handig als je ongeveer weet wanneer een probleem begon, of als je de logs rond een deployment wilt controleren zonder een grote hoeveelheid niet-relevante regels op te halen.

Kinsta bewaart sitelogs maximaal vier dagen, dus de opgevraagde periode moet binnen die bewaartermijn vallen. Lees meer in de API-documentatie.

Controleren of er een downloadbare backup beschikbaar is

Je kunt één keer per week een downloadbare backup genereren. Met het nieuwe endpoint next-downloadable-backup-available controleer je nu vooraf of er alweer een nieuwe beschikbaar is voordat je de actie start.

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

Kan er nog geen nieuwe downloadbare backup worden gemaakt, dan staat in het antwoord wanneer dat wel kan:

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

Ook het bestaande endpoint voor het genereren van een downloadbare backup (downloadable-backups) is bijgewerkt. Het geeft nu een foutmelding als je een nieuwe backup aanvraagt vóór het resetmoment.

Wordt een verzoek geaccepteerd, dan bevat het antwoord een operation ID:

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

Voorbeeld van een antwoord:

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

Alle details over het controleren van de beschikbaarheid en het maken van een downloadbare backup vind je in de API-documentatie.

Integreer meer MyKinsta-workflows in je eigen tools

Deze releases breiden de programmatische toegang uit naar verschillende dagelijkse MyKinsta-workflows.

Samen maken ze het makkelijker om WordPress omgevingen consistent te beheren via interne dashboards, provisioningscripts, deployworkflows en andere automatiseringen die je bouwt met de Kinsta API.