Wanneer er een dringend supportticket binnenkomt, is het instinct om er meteen in te duiken en het probleem zo snel mogelijk op te lossen. Op een live WordPress site kan die drang naar snelheid echter averechts werken.
Een mislukte plugin-update, een snelle configuratieaanpassing of een overhaaste databasewijziging kan een site van “gedeeltelijk kapot” naar volledig offline brengen. Zonder een recente backup is er geen schone weg terug.
In deze gids leer je hoe je die stap automatiseert. Door Zendesk te koppelen aan de Kinsta API activeert elk urgent WordPress ticket automatisch een backup, nog voordat een professional het ticket opent. Het resultaat is een veiliger en consistenter incident response-proces, met een herstelpunt dat al klaarstaat.
Waarom bureaus eerst een backup moeten maken voordat ze iets repareren
Een plugin-conflict, een mislukte database-query of een onvolledige update op een live WordPress site zonder backup is lastig te herstellen. Elke wijziging die je doorvoert voordat er een backup is gemaakt, betekent dat er geen functionerend punt is om naar terug te keren als er iets misgaat.
Het beheren van sites van meerdere klanten betekent dat je erop moet vertrouwen dat degene die het ticket oppakt een backup maakt voordat hij of zij begint. En precies bij die handmatige stap gaat het vaak mis.
Voor Pixeled Eggs staat er bijvoorbeeld veel op het spel, omdat hun klanten mensen in een crisissituatie helpen. Iemand die op zoek is naar geestelijke gezondheidszorg of noodhulp verwacht dat de site gewoon laadt. Een mislukte herstelpoging is dan een ramp.
De probleemloze oplossing en de tijd die we ons ontwikkelteam hebben bespaard, hebben onze investering ruimschoots terugverdiend. Het betekent dat we ons kunnen richten op waar we goed in zijn: het ontwerpen en ontwikkelen van goed presterende WordPress sites voor doelgerichte klanten.
Wat je nodig hebt voordat je begint
Voor deze handleiding heb je nodig:
- Een Kinsta-account met ten minste één WordPress site in een live-omgeving.
- Een Zendesk-account op een Suite Team pakket of hoger (of een Support Team-, Professional- of Enterprise pakket). Webhooks en Triggers zijn op al deze niveaus beschikbaar.
- Beheerderstoegang binnen Zendesk om webhooks en Triggers aan te maken.
- Node.js lokaal geïnstalleerd.
Om te authenticeren met de Kinsta API ga je in MyKinsta naar [Jouw bedrijf] > Bedrijfsinstellingen > API-sleutels en klik je op API-sleutel aanmaken.
Hier geef je de sleutel een naam, stel je een vervalmoment in en klik je op Genereren. De sleutel wordt maar één keer getoond, dus kopieer hem voordat je het paneel sluit. Je hebt ook een site-ID nodig. Die verschijnt in de MyKinsta URL wanneer je een site opent, of je kunt GET /sites opvragen zodra je sleutel is ingesteld.
Voeg de API-sleutel hoe dan ook toe aan een .env-bestand in de project root:
KINSTA_API_KEY=your_api_key_hereHoud er rekening mee dat de site-ID en de omgevings-ID twee verschillende dingen zijn: de agent voert de site-ID in, en de middleware roept GET /sites/{siteId}/environments aan om de omgevings-ID op te halen. Daarnaast komt het toegangsniveau van een API-sleutel overeen met de rol die de sleutel heeft aangemaakt: ontwikkelaarssleutels hebben beperktere rechten dan die van eigenaren of beheerders. Levert een verzoek een toestemmingsfout op, dan is dit het eerste om te controleren.
Aanvullende vereisten voor ontwikkeling
Bij lokale ontwikkeling draait de middleware op localhost, en die kan Zendesk niet rechtstreeks bereiken. Met een tunneling-tool zoals ngrok stel je een lokale poort open naar het internet via een tijdelijke publieke URL, die je tijdens de ontwikkeling kunt gebruiken als webhook-endpoint. Zodra de integratie lokaal end-to-end werkt, vervang je die URL door het adres van de uitgerolde middleware.
Je hebt ook een custom ticketveld in Zendesk nodig om de Kinsta site-ID van een ticket mee te geven in de payload van de webhook. Navigeer in het optiesmenu van Zendesk aan de rechterkant van het scherm naar Objects and rules > Tickets > Fields en maak een nieuw tekstveld aan.
Geef het veld vervolgens een herkenbare naam en noteer de numerieke veld-ID die Zendesk eraan toekent. Wanneer een agent een ticket opent voor een WordPress incident, vult hij of zij dit veld in met de site-ID van de betreffende site.
Zo integreer je Zendesk met Kinsta via de Kinsta API
Om een backup te starten zodra een relevant supportticket binnenkomt, ontvangt de Node.js-middleware webhook-calls van Zendesk. Van daaruit wordt een Kinsta site-ID omgezet in een omgevings-ID, waarna een getagde handmatige backup wordt gestart.
De Zendesk-kant bestaat uit twee objecten: een webhook die naar het middleware-endpoint wijst, en een Trigger die afgaat wanneer een geschikt ticket binnenkomt.
1. De Zendesk-webhook aanmaken
In Zendesk zijn een webhook en een Trigger twee aparte objecten. Je maakt eerst de webhook aan en koppelt die daarna als actie aan de Trigger, niet andersom. De verbindingsmethode van een webhook kun je na het aanmaken bovendien niet meer wijzigen, dus de volgorde is belangrijk.
Om de webhook aan te maken open je de Zendesk-opties, navigeer je naar Apps and integrations > Webhooks > Webhooks en klik je vervolgens op Create webhook.
Kies als verbindingsmethode Trigger or automation. Klik op Next en voer een naam in. Vul voor de endpoint-URL voorlopig een placeholder in, want die werk je bij zodra de middleware is uitgerold. Voeg /backup toe aan die URL, stel de verzoekmethode in op POST en het request format op JSON.
Voor de authenticatiemethode is Bearer token een praktische keuze, omdat je tijdens het configureren van de middleware een controle toevoegt die het inkomende verzoek valideert. Zendesk bevat ook een signature header (x-zendesk-webhook-signature) waarmee je verzoeken kunt verifiëren. Zodra je de webhook hebt aangemaakt, toont Zendesk hem in het webhooks-paneel totdat je hem aan een Trigger koppelt.
2. De Zendesk-Trigger instellen
Met de webhook op zijn plaats navigeer je naar Objects and rules > Business rules > Triggers en klik je op Create trigger.
Geef de trigger een naam en stel hem onder de sectie Conditions zo in dat hij afgaat wanneer het ticket is aangemaakt, de prioriteit Urgent is, het custom veld aanwezig is en de tags wordpress-emergency bevatten. Door deze combinatie gaat de trigger alleen af op nieuwe tickets die een supportmedewerker expliciet heeft gemarkeerd als een actief WordPress incident.
Klik vervolgens op Actions > Add action, selecteer Notify by > Active webhook en kies je webhook. Hiermee open je de editor voor de request payload, waarin je definieert wat Zendesk naar je middleware stuurt. De payload is standaard JSON, en Zendesk ondersteunt placeholder-syntax om ticketgegevens te injecteren wanneer de webhook afgaat.
Het format voor het custom veld is {{ticket.custom_fields.FIELD_ID}}, waarbij FIELD_ID de numerieke ID is van het custom veld dat je bij de vereisten hebt aangemaakt:
{
"ticket_id": "{{ticket.id}}",
"site_id": "{{ticket.custom_fields.12345678}}" // Replace the numeric placeholder with the Zendesk field ID value.
}Door dit te definiëren geeft Zendesk de Kinsta site-ID van het ticket automatisch door aan de middleware.
3. Het middleware-endpoint bouwen
Middleware zorgt ervoor dat Zendesk en de Kinsta API met elkaar kunnen communiceren. Express.js is een minimaal Node.js-webframework dat routing afhandelt, request bodies parseert en je het POST /backup-endpoint laat definiëren dat Zendesk aanroept. Zodra je een nieuwe projectmap hebt geïnitialiseerd, installeer je beide dependencies:
npm init -y
npm install express dotenvHier levert express de server- en routinglaag; dotenv laadt je .env-bestand zodat je API-sleutel tijdens runtime beschikbaar is zonder dat die in je broncode verschijnt.
Door een app.js-bestand aan te maken, start de server Express, parseert die inkomende JSON en definieert die een POST /backup-route die de Zendesk-payload ontvangt:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KinstaAPIUrl = 'https://api.kinsta.com/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
// Kinsta API calls placeholder
res.status(200).json({ message: 'Received' });
});
app.listen(3000, () => console.log('Server running on port 3000'));Controleer voor productiegebruik ook of het verzoek daadwerkelijk van Zendesk afkomstig is. Bij elke call bevat het de headers x-zendesk-webhook-signature en x-zendesk-webhook-signature-timestamp, waarmee je de payload kunt valideren tegen je webhook.
4. Authenticeren met de Kinsta API
Alle verzoeken aan de Kinsta API gebruiken Bearer token-authenticatie: de Authorization header bevat je API-sleutel, en de headers-constante die in app.js is gedefinieerd, regelt dat voor elk verzoek in de applicatie.
De regel require('dotenv').config() bovenaan het bestand laadt .env voordat er iets anders wordt uitgevoerd, zodat process.env.KINSTA_API_KEY tijdens runtime resolvet naar je werkelijke sleutel. De sleutel verschijnt nooit in de broncode.
Wat de middleware vervolgens nodig heeft, is de omgevings-ID van de site, waarbij het backup-endpoint van Kinsta betrokken is. Dit doe je door een functie toe te voegen onder de headers-constante:
const getEnvironmentId = async (siteId) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/${siteId}/environments`,
{ method: 'GET', headers }
);
const data = await resp.json();
return data.site.environments[0].id;
};Deze functie roept GET /sites/{siteId}/environments aan en retourneert de ID van de eerste omgeving in de respons, die overeenkomt met de live-omgeving. Gebruiken je sites meerdere omgevingen en moet je een specifieke omgeving aanspreken, dan kun je matchen op de omgevingsnaam in plaats van het eerste resultaat te nemen.
5. De backup activeren via de Kinsta API
Om de backup te maken roept de middleware POST /sites/environments/{envId}/manual-backups aan, met een extra functie onder getEnvironmentId:
const triggerBackup = async (envId, tag) => {
const resp = await fetch(
`${KinstaAPIUrl}/sites/environments/${envId}/manual-backups`,
{
method: 'POST',
headers,
body: JSON.stringify({ tag })
}
);
const data = await resp.json();
return data;
};De parameter tag labelt de backup, waardoor die eenvoudig te herkennen is in MyKinsta. Door het Zendesk ticket-ID in de tag te gebruiken, kan iedereen die de backup-lijst bekijkt de backup terugleiden naar het incident dat de aanleiding vormde.
Werk tot slot de POST /backup-route bij zodat beide functies achter elkaar worden aangeroepen:
app.post('/backup', async (req, res) => {
const { ticket_id, site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'Missing site ID' });
}
try {
const envId = await getEnvironmentId(site_id);
const tag = `pre-remediation-${ticket_id || 'manual'}`;
const result = await triggerBackup(envId, tag);
res.status(200).json(result);
} catch (err) {
console.error(err);
res.status(500).json({ message: 'Backup failed' });
}
});Een geslaagd verzoek aan het backup-endpoint retourneert een 202-status met een respons die bevestigt dat de bewerking loopt:
{
"operation_id": "backups:add-manual-abc123",
"message": "Adding a manual backup to environment in progress.",
"status": 202
}Het 202-antwoord is echter geen bevestiging dat de backup is voltooid. Handmatige backups zijn async, dus je controleert het endpoint GET /operations/{operation_id} totdat de status terugkomt als voltooid. Voor de meeste workflows is een 202 voldoende om een ticket te openen.
Zodra je node app.js uitvoert en een testverzoek verstuurt met een geldige site-ID en ticket-ID in de body, controleer je of de backup in MyKinsta verschijnt met de juiste tag.
Kinsta helpt sites van je klanten te beschermen op het moment dat er iets misgaat
Dankzij deze integratie activeren urgente WordPress support-tickets in Zendesk meteen een backup. De middleware roept de Kinsta API aan om een getagde momentopname te maken, allemaal nog voordat een technicus het ticket opent.
Voor lokale ontwikkeling verzorgt ngrok de verbinding tussen Zendesk en localhost. Ben je klaar om de middleware naar een permanent endpoint te verplaatsen, dan is Sevalla een logische keuze. Je pusht het project naar een Git-provider, verbindt de repo, voegt je omgevingsvariabele toe in de deploy-instellingen en werkt de webhook-endpoint URL in Zendesk bij zodat die naar het live-adres wijst.
Beheer je klantsites op grote schaal, dan sluit de Automatische Updates add-on van Kinsta naadloos aan op deze workflow. Die houdt plugins en thema’s up-to-date, voert na elke update geautomatiseerde visuele tests uit en draait de wijziging terug als er iets kapotgaat. Bovendien stel je dit per site in op een eigen schema.
Heb je vragen, neem dan gerust contact op met het ondersteuningsteam.
