Het beheren van losse WordPress sites kost tijd. Voor bureaus die tientallen of zelfs honderden sites beheren, kunnen taken zoals het aanmaken van omgevingen, het wissen van caches, het toevoegen van domeinen of het herstellen van backups zich snel opstapelen. Het team wordt trager door de repetitieve loop.

En dit is het typische patroon voor velen:

  • Nieuwe klant binnengehaald → ontwikkelaar stelt WordPress handmatig in, voegt domeinen toe en configureert plugins
  • Iemand pusht een deployment → het team moet inloggen en handmatig de caches leegmaken
  • Een klant meldt een bug → het malwareteam controleert de logboeken handmatig en misschien wordt de site teruggedraaid via een backup

Geen van deze taken is moeilijk, maar ze herhaaldelijk uitvoeren vreet tijd die geïnvesteerd zou moeten worden in belangrijker werk.

Daarom biedt Kinsta niet alleen een overzichtelijk, intuïtief dashboard, maar ook de Kinsta API om de routinetaken te automatiseren die je bureau elke dag uitvoert.

Laten we eens kijken naar enkele WordPress beheertaken die bureaus automatiseren met de Kinsta API.

WordPress sites maken en klonen

Het installeren van een nieuwe WordPress site is waarschijnlijk het meest voorkomende wat je team doet. In het beginstadium van het runnen van je bureau voelt het niet als een grote klus, omdat je misschien maar vijf tot 10 sites per week maakt. Maar naarmate je groeit, verandert dat. Je krijgt te maken met kansen zoals Black Friday of een grote roll-out van een klant waarbij je in een paar dagen tientallen sites moet lanceren.

Op dat moment kun je het niet handmatig doen. Of je vertraagt, neemt meer mensen aan en traint ze (wat tijd en geld kost), of je automatiseert het.

Met de Kinsta API kun je dit aansluiten op je interne tool of dashboard, zodat het maken van een nieuwe WordPress site net zo eenvoudig wordt als het klikken op een knop.

Stel dat iemand zich inschrijft op de site van je bureau en betaalt. Je zou een script kunnen hebben dat de resultaten van het inschrijfformulier neemt en de API aanroept om een nieuwe WordPress site te maken met je basisthema.

Dit is niet theoretisch. De API heeft al alles wat je nodig hebt:

Als je veel sites beheert, scheelt dit elke week uren in je instelproces.

Domeinen programmatisch beheren

Dit is een no-brainer als je op grote schaal sites van klanten beheert.

Bureaus voegen regelmatig domeinen toe of veranderen ze, bijvoorbeeld tijdens het inwerken of tijdens een volledige rebranding. Als je een groot bureau bent, wil je misschien de tijd verkorten die het kost om door MyKinsta te klikken om domeinen toe te voegen, DNS te verifiëren en SSL in te stellen.

Met de Kinsta API kun je dit allemaal automatiseren.

Dit is een veelvoorkomend scenario uit de praktijk: Een nieuwe klant meldt zich aan. Je hebt hun domeinnaam en DNS al ingesteld in je CRM. Je interne systeem controleert of de DNS records naar Kinsta wijzen (misschien met behulp van een DNS lookup achter de schermen), en op het moment dat dat is bevestigd, roept het de API aan om:

  • Het domein te koppelen
  • Het in te stellen als primair domein
  • Custom SSL te uploaden als dat nodig is

Je zou zelfs een Slack melding kunnen krijgen die zegt “✅ klantdomein.com is gekoppeld en SSL is actief.”

Een ander scenario: Laten we zeggen dat je 20 sites van klanten in bulk aan het rebranden bent. Om elke omgeving bij te werken met nieuwe domeinen, ze over te zetten en SSL automatisch toe te passen, zet je alle domeinwijzigingen in een wachtrij en loop je door de API in plaats van ze allemaal met de hand bij te werken.

Enkele van de eindpunten die dit mogelijk maken zijn als volgt:

Dit is meer dan alleen een nice-to-have. Dit soort automatisering bespaart letterlijk uren en elimineert menselijke fouten voor bureaus die deze taak vijf tot tien keer per week uitvoeren.

Als je nog verder wilt gaan, kun je deze controle zelfs in je eigen interne dashboard opnemen. Klik op “Domein toewijzen”, kies de site en het domein, en je app roept de Kinsta API aan.

Backups beheren: lijst weergeven, herstellen of downloaden

Soms kan een implementatie mislukken, kunnen plugins zich misdragen of kan een klant een probleem melden op de live site. Met MyKinsta heb je al betrouwbare backups beschikbaar. Maar als je meerdere sites beheert en snel moet handelen, helpt het om de controle over backups direct in je workflow te hebben.

Dat is waar de API om de hoek komt kijken. Bureaus nemen dit op in hun deploymentworkflows zodat:

  • Een handmatige backup wordt gemaakt vlak voor een implementatie
  • Als er iets fout gaat, er automatisch een restore wordt uitgevoerd
  • Teams Slack of hun dashboard niet hoeven te verlaten om een site terug te zetten

Je kunt bijvoorbeeld een Slack commando instellen als:

/restore site-name to yesterday

Dit zou je interne service aanroepen, die vervolgens het herstel eindpunt triggert. Of stel je een “Quick Restore” knop met één klik voor in je interne tool, en de API brengt de site terug naar een stabiele staat zonder dat je hoeft in te loggen op MyKinsta.

Dit is wat er mogelijk is met de beschikbare eindpunten:

De API geeft je team de mogelijkheid om snel te handelen, vooral op drukke momenten.

Plugins en thema’s in bulk bijwerken

We hebben een gids geschreven die uitlegt hoe je een eenvoudige tool kunt bouwen met de Kinsta API om verouderde plugins in bulk te controleren en bij te werken op meerdere WordPress sites vanaf een enkel dashboard.

Mini web app gebouwd om WordPress plugin updates te automatiseren met behulp van de Kinsta API.
Mini web app gebouwd om WordPress plugin updates te automatiseren met behulp van de Kinsta API.

Datzelfde idee werkt vandaag de dag nog steeds, ook al biedt Kinsta nu automatische plugin- en thema-updates als een premium add-on (die daarbij ook visuele tests en auto-rollbacks uitvoert).

Kinsta's Automatische Plugin Updates add-on.
Kinsta’s Automatische Plugin Updates add-on.

Maar als je team een ander soort controle wil, dan biedt de API die vrijheid. Je kunt alle plugins van je klantensites in één overzicht laten zien, de verouderde plugins markeren en je ontwikkelaars laten kiezen welke ze willen bijwerken.

Misschien kun je je QA team er een paar laten markeren om te testen voordat ze updates naar de productie pushen. Je kunt ook de bloat opruimen door inactieve plugins eruit te filteren en ze direct te verwijderen.

Het plugins eindpunt retourneert echte details zoals:

{
  "name": "akismet",
  "title": "Akismet Anti-Spam",
  "status": "active",
  "version": "1.0.0",
  "update": "available",
  "update_version": "1.0.1"
}

Met die informatie kun je elke logica bouwen die je maar wilt:

  • Plugin-tellingen per site tonen
  • Versiedrift detecteren
  • Updates triggeren voor meerdere omgevingen
  • Of zelfs een Slack-bot bouwen die antwoordt met “deze site heeft 4 verouderde plugins” en een knop om het te repareren

Dus hoewel de nieuwe add-on pluginbeheer voor de meeste teams oplost, opent de API een heel nieuw niveau van zichtbaarheid en aangepaste automatisering die bij jouw werkstijl zou kunnen passen.

Cache wissen, PHP herstarten, naar live zetten

De eindpunten clear cache en restart PHP staan in de top drie van meest gebruikte eindpunten in de Kinsta API, en het is niet moeilijk om te zien waarom.

Kinsta API gebruiksdashboard met verzoekstatistieken.
Kinsta API gebruiksdashboard met verzoekstatistieken.

Direct na een deployment is het wissen van caches meestal stap één. Hetzelfde geldt voor het herstarten van PHP als er iets misgaat. Dit zijn geen “fancy” operaties. Het zijn taken die je team vaak uitvoert. Het zijn dus ook het soort dingen die geautomatiseerd zouden moeten worden.

Als je team Git over SSH al gebruikt om te deployen naar Kinsta, dan kun je deze API calls direct in je CI pijplijn integreren, misschien via GitHub Actions. Zonder dat een gebruiker inlogt op MyKinsta, reset alles zichzelf met een enkele schone push.

Hier is een voorbeeldpijplijn:

name: Deploy to Kinsta and clear cache

on:
  push:
    branches:
      - main

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Deploy through SSH
        uses: appleboy/[email protected]
        with:
          host: ${{ secrets.KINSTA_SERVER_IP }}
          username: ${{ secrets.KINSTA_USERNAME }}
          password: ${{ secrets.KINSTA_PASSWORD }}
          port: ${{ secrets.KINSTA_PORT }}
          script: |
            cd /www/your-site/public
            git fetch origin main
            git reset --hard origin/main

      - name: Clear Kinsta cache
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/clear-cache \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

      - name: Restart PHP
        run: |
          curl -X POST https://api.kinsta.com/v2/environments/${{ secrets.KINSTA_ENV_ID }}/tools/restart-php \
          -H "Authorization: Bearer ${{ secrets.KINSTA_API_KEY }}" \
          -H "Content-Type: application/json"

Dit is eenvoudig, maar krachtig. Je kunt nog verder gaan:

  • Voeg een knop “Cache wissen” toe aan je interne beheerpaneel
  • Activeer het wissen van de cache via Slack, met een bot commando zoals /cache-clear client-name
  • Neem het wissen van de cache en het opnieuw opstarten van PHP op als onderdeel van je test-to-live deploymentflow

En als je het Push to Live eindpunt gebruikt, worden de dingen nog interessanter. Je hoeft niet alles te pushen, want de API ondersteunt het selectief pushen van bestanden met push_files_option: 'SPECIFIC_FILES'.

Je kunt je deployments dus zo aanpassen dat je alleen wijzigingen aan je plugin of thema pusht:

{
  "source_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "target_env_id": "54fb80af-576c-4fdc-ba4f-b596c83f15a1",
  "push_db": true,
  "push_files": true,
  "run_search_and_replace": true,
  "push_files_option": "SPECIFIC_FILES",
  "file_list": [
    "wp-content/plugins",
    "wp-content/themes",
    "wp-content/uploads"
  ]
}

Dit is het soort dingen dat het leven van ontwikkelaars makkelijker maakt en de zaken vlot houdt voor je klanten.

Toeganglogs voor monitoring of debugging

Als bureau beheert je team veel sites van klanten. Je weet al dat tegen de tijd dat een klant zegt: “De site ligt plat”, hij meestal al een tijdje kapot is.

Dat is waar het logboek eindpunt je kan helpen. In plaats van te wachten op klachten van je klanten, kun je direct logs ophalen via de API en ze weergeven in je interne dashboard. Nog beter is het om een eenvoudig waarschuwingssysteem op te zetten dat je team in Slack of per e-mail waarschuwt als er iets mis lijkt te zijn.

Je hoeft MyKinsta niet elke keer te openen als iemand een 500-fout meldt. Haal simpelweg de laatste fout- of toegangslogs op, ontleed de uitvoer en geef de resultaten weer waar je team al werkt.

Je hebt alleen de omgevings-ID nodig en het type log dat je wilt, zoals error, access, of kinsta-cache-perf. Je kunt ook het aantal regels dat wordt geretourneerd beperken:

curl -i -X GET \
  'https://api.kinsta.com/v2/sites/environments/{env_id}/logs?file_name=error&lines=1000' \
  -H 'Authorization: Bearer '

Je krijgt een simpele string met logboekcontent terug. Van daaruit kun je uitbouwen wat bij jouw werkproces past:

  • De meest recente foutlogs voor elke klantensite in het dashboard van je bureau tonen
  • 500’s, trage queries of mislukte cron jobs markeren
  • Waarschuwingen triggeren wanneer er foutenpieken optreden
  • Laat je ontwikkelaars /show-logs client-x intypen in Slack en bekijk direct live output

Dat is het soort zichtbaarheid dat je behoedt voor “uh oh” momenten tijdens gesprekken met klanten.

Een praktijkvoorbeeld: Hoe Sod de API gebruikt om 400+ sites te beheren

Als je je afvraagt of echte bureaus de Kinsta API op deze manier gebruiken, dat doen ze.

Neem bijvoorbeeld Straight Out Digital (Sod), een full-service bureau in Melbourne, Australië, dat meer dan 400 WordPress sites beheert. Toen hun klantenlijst explodeerde, kon de handmatige manier van werken het gewoon niet meer bijbenen. Dus bouwden ze interne tools bovenop de Kinsta API om alles te automatiseren, van site provisioning tot plugin-updates.

Ze gebruiken het om:

  • Nieuwe sites automatisch op te starten bij het onboarden van klanten
  • Bestaande opstellingen te klonen zonder in te loggen op het dashboard
  • Bulkcontroles en updates van plugin uit te voeren voor hun hele portfolio
  • Waarschuwingen te triggeren wanneer er fouten in de logs verschijnen
  • Problemen voor te blijven zonder te wachten op tickets van klanten

Ze gebruiken MyKinsta nog steeds dagelijks, maar de API helpt hen het repetitieve werk te vermijden. In hun eigen woorden:

De Kinsta API heeft ons in staat gesteld om interne tools te ontwikkelen die cruciale processen automatiseren, zoals site provisioning en het uitvoeren van bulkbewerkingen op onze websites, waardoor we aanzienlijke tijd en moeite besparen,” aldus Sod Development Lead Pete Brundle.

Dit is het bewijs dat deze workflows niet theoretisch zijn. Bureaus zoals Sod gebruiken ze al en het bedrijf heeft hierdoor de 400 sites overschreden.

Samenvatting

Als je een bureau hebt met meerdere WordPress sites, dan is de Kinsta API niet alleen een leuk hebbedingetje. Het is de manier om tijd en geld te besparen.

Of je het nu in je CI pijplijn plugt, acties activeert vanuit je interne tools of gewoon het leven van je ontwikkelaars makkelijker wilt maken, de onderdelen zijn er al. Je hoeft je proces niet helemaal opnieuw op te bouwen. Je hoeft alleen maar de onderdelen aan te sluiten die je team het meest vertragen.

En zoals we hebben gezien bij bureaus als Sod, worden de voordelen groter naarmate je schaalt.

Verken de Kinsta API documentatie om te zien wat er allemaal mogelijk is, genereer je API sleutel in MyKinsta en duik in de stap-voor-stap tutorials over het bouwen van Slack bots, het implementeren via Git en meer!

Joel Olawanle Kinsta

Joel is een Frontend developer die bij Kinsta werkt als Technical Editor. Hij is een gepassioneerd leraar met liefde voor open source en heeft meer dan 200 technische artikelen geschreven, voornamelijk over JavaScript en zijn frameworks.