Wanneer een deal wordt gesloten in Salesforce, zijn nog steeds een aantal handmatige stappen nodig om te zorgen dat de bijbehorende site live gaat. Een ontwikkelaar moet de juiste klantsite opzoeken in MyKinsta, een backup maken en de testomgeving naar productie pushen, allemaal op het juiste moment.
Met de Kinsta API verbind je deze twee delen van de workflow, zodat het goedkeuren van de deal automatisch de lancering in gang zet. In plaats van te leunen op iemand die elke stap handmatig uitvoert, draait het proces zodra de Opportunity de doel-fase bereikt.
De opzet is simpel: start een batch taken in MyKinsta wanneer een Salesforce Opportunity wordt bijgewerkt, en maak handmatig ingrijpen na de uitrol overbodig. Je klant krijgt zo een sneller pad van goedkeuring naar een live site, zonder te wachten op handoffs tussen teams.
Wat je nodig hebt voordat je begint
Om deze tutorial te volgen heb je een Kinsta account nodig met een WordPress site die zowel een testomgeving als een live-omgeving heeft, een Salesforce account met toegang tot Flow Builder, en Node.js lokaal geïnstalleerd voor de middleware.
Om je te authenticeren bij de Kinsta API ga je in MyKinsta naar Je naam > Bedrijfsinstellingen > API-sleutels en klik je op API-sleutel aanmaken.
Geef de sleutel een naam, stel een vervalmoment in en klik op Genereren. De sleutel wordt maar één keer getoond, dus kopieer hem voordat je het venster sluit. Bewaar hem in een .env bestand in de project root, naast je Bedrijfs-ID die je vindt onder Bedrijfsinstellingen > Factureringsgegevens:
KINSTA_API_KEY=your_api_key_here
KINSTA_COMPANY_ID=your_company_id_here
Je hebt ook een custom tekstveld nodig op het Salesforce Opportunity-object om de Kinsta site-ID per klantproject op te slaan. Ga naar Setup > Object Manager en daarna naar Opportunity > Fields & Relationships.
Voeg hier een Field Label toe; Salesforce genereert dan een Field Name die je moet noteren. Stel de Length in op 255 en sla je wijzigingen op.
De site-ID is een UUID die Kinsta toekent bij het aanmaken. Hij verschijnt in de MyKinsta URL wanneer je een site opent, of je haalt hem eenmalig op door GET /sites aan te roepen met je API-sleutel:
https://my.knst.lol/sites/details/hyut4927-d324-4044-b794-67ap0rbf20bj/…
Je gebruikt de site-ID in een custom veld op elke Opportunity om de hele workflow te activeren.
Hoe je WordPress go-live automatiseert vanuit Salesforce met de Kinsta API
In Salesforce bewaakt een Record-Triggered Flow de Opportunity-stage en vuurt een HTTP-callout af zodra de omgeving verandert.
De Node.js middleware ontvangt de site-ID, roept de Kinsta API aan om een backup van de testomgeving te maken, wacht tot die operatie klaar is en pusht daarna de testomgeving naar productie. Het meeste werk zit in Salesforce: het correct instellen van rechten en toegang.
1. Een Named Credential instellen
Salesforce heeft een handige manier om API-sleutels op te slaan: een External Credential, die het eigenlijke geheim bevat, en een Named Credential, die de URL van het endpoint definieert en er verbinding mee maakt.
Open in Salesforce vanuit het hoofdmenu het Setup-scherm:
Zoek hier naar Named Credentials, open het tabblad External Credentials en klik op New. Geef het een naam en een label en zet het authenticatieprotocol op Custom. Zo kun je een Bearer token-header definiëren in plaats van een beheerde OAuth-flow.
Nadat je het hebt opgeslagen, scroll je naar Principals en klik je op New. Geef de principal een naam, zoals KinstaKey, en voer de Kinsta API-sleutel in als waarde.
Voeg nu een Custom Header toe met de naam Authorization en een waarde die naar de principal verwijst, zodat elke uitgaande call de API-sleutel als Bearer token meestuurt.
Als je de External Credential hebt opgeslagen, ga je naar het tabblad Named Credentials, klik je op New, stel je de URL in op je middleware endpoint, vul je de vereiste velden in en selecteer je de External Credential in de sectie Authentication.
Gebruikersrechten instellen
Je moet ook een Permission Set inschakelen voor de principal van de External Credential. Die geeft je gebruikersprofiel de rechten om de Kinsta API aan te roepen. Ga hiervoor naar Setup > Permission Sets en klik op New.
Geef het een naam en sla het op. Open daarna de Permission Set opnieuw en klik op Edit bij External Credential Principal Access. Verplaats de External Credential principal naar de ingeschakelde lijst:
Sla tot slot je wijzigingen op, ga terug naar de Permission Set en klik op Manage Assignments in de bovenste werkbalk:
Gebruik in dit scherm Add Assignment om je gebruikersprofiel te koppelen en toegang te geven tot de Kinsta API.
2. Maak een Record-Triggered Flow op het Opportunity-object
Open daarna de Salesforce App Launcher, zoek op het volgende scherm naar Flows, klik op New en selecteer Record-Triggered Flow.
Zodra Flow Builder opent, stel je de volgende opties in:
- Kies Opportunity als object.
- Laat de trigger afgaan wanneer een record wordt bijgewerkt.
- Kies All Conditions Are Met (AND) in het menu Condition Requirements.
- In de velden die dan verschijnen kies je Stage als Field, Equals als operator en Closed Won als Value.
- Selecteer onder When to Run the Flow for Updated Records de optie Only when a record is updated to meet the condition requirements.
Door de flow alleen op bijgewerkte records te draaien, voorkom je dat de uitrol meer dan één keer draait. Zonder deze optie draait de flow bij elke volgende opslag nadat de stage is gewijzigd.
Selecteer tot slot onder Optimize the Flow For de optie Actions and Related Records en zet daarna de schakelaar Add Asynchronous Path aan, die de callout mogelijk maakt en de twee nieuwe ‘paden’ toont.
3. Configureer het asynchrone pad en voeg een HTTP Callout-actie toe
Salesforce staat geen HTTP-callouts toe binnen een open trigger-transactie. Elke callout moet naar het pad Run Asynchronously. Acties op dit pad draaien pas nadat de trigger-transactie is vastgelegd.
Voeg op het pad Run Asynchronously een Action-element toe en selecteer onderaan in het rechterpaneel Create HTTP Callout.
Geef de callout een naam en wijs de URL naar je middleware endpoint, met /go-live als slug. Je kunt een placeholder-URL gebruiken totdat de middleware is uitgerold. Voor lokale ontwikkeling maakt ngrok je lokale poort bereikbaar via een openbare URL. Selecteer hier ook het Named Credential.
Zodra je op Next klikt, wijs je een POST-methode toe en geef je de callout een label. Als je verder klikt, moet je een voorbeeld-JSON voor het request en de response opgeven. Gebruik voor het request het volgende:
{
"site_id": "fbab4927-e354-4044-b226-29ac0fbd20ca"
}
Als je in het volgende paneel Connect with Sample Response selecteert, kun je de knop Connect gebruiken om de verbinding tot nu toe te testen. Die geeft echter een 502-fout totdat je de middleware hebt geschreven. Klik nu op Use Example Response en voeg het volgende toe:
{
"message": "Received"
}
Kom hier later op terug om de verbinding verder te testen.
4. Stel een request body in bij Flow Builder
Je moet wat handmatig werk verzetten om de request body voor de Action in te stellen. Begin met New Resource in het uitklapmenu Set Request Body:
Hier voer je een naam in (zoals requestBody), sla je die op en selecteer je die als Value voor de request body. Voeg daarna in Flow Builder een Assignment-element toe, geef het een label en een naam en vul in het uitklapmenu Set Variable Values het volgende in:
- Variable:
site_id - Operator: Equals
- Value: Blader door het submenu Triggering Opportunity tot je bij Kinsta Site ID komt.
Daarmee is de Salesforce-kant klaar. De volgende stap is het bouwen van de Node app.
5. Bouw de Node.js middleware
Nu de flow is geconfigureerd, vinden de Kinsta API-calls plaats in de middleware. Start een nieuw Node.js project en installeer de dependencies:
npm init -y
npm install express dotenv
Express.js verzorgt de routing en request parsing. dotenv laadt het .env bestand, zodat je API-sleutel tijdens runtime beschikbaar is zonder in je broncode te belanden. Maak daarna app.js aan in de project root:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KINSTA_API_URL = 'https://api.knst.lol/v2';
const headers = {
'Content-Type': 'application/json',
Authorization: `Bearer ${process.env.KINSTA_API_KEY}`
};
app.post('/go-live', async (req, res) => {
const { site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'site_id is required' });
}
// Kinsta API calls added in the steps below
res.status(200).json({ message: 'Received' });
});
app.listen(3000, () => console.log('Middleware running on port 3000'));De headers constante regelt de Bearer token-authenticatie voor elk Kinsta API-verzoek in de app. Let op: de bedrijfs-ID wordt, waar nodig voor endpoints zoals GET /sites, meegegeven als queryparameter (niet in de Authorization-header). De aanroep require('dotenv').config() bovenaan zorgt dat de sleutel uit .env wordt geladen voordat er iets anders draait.
Voordat er een backup wordt gemaakt, heeft de middleware de omgevings-ID’s nodig voor zowel de testomgeving als de live-omgeving. Voeg onder de headers constante een getEnvironments functie toe:
const getEnvironments = async (siteId) => {
const resp = await fetch(
`${KINSTA_API_URL}/sites/${siteId}/environments`,
{ method: 'GET', headers }
);
const data = await resp.json();
return data.site.environments;
};Dit roept GET /sites/{siteId}/environments aan en retourneert de volledige array met omgevingen.
6. Maak een handmatige backup van de testomgeving
Het pushen van een omgeving naar productie overschrijft de live site. Door eerst een backup te maken heb je een herstelpunt als de push een conflict blootlegt dat tijdens het testen in de testomgeving niet naar boven kwam.
Voeg hier onder getEnvironments een createBackup functie toe:
const createBackup = async (envId) => {
const resp = await fetch(
`${KINSTA_API_URL}/sites/environments/${envId}/manual-backups`,
{
method: 'POST',
headers,
body: JSON.stringify({ tag: 'pre-launch-backup' })
}
);
const data = await resp.json();
return data;
};Kinsta verwerkt de backup asynchroon en retourneert 202 Accepted met een operation_id in plaats van een afgerond resultaat:
{
"operation_id": "backups:add-manual-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"message": "Adding a manual backup to environment in progress",
"status": 202
}Om de uitvoering te pauzeren tot de backup klaar is, voordat de push start, voeg je onder createBackup een pollOperation functie toe:
const pollOperation = async (operationId, intervalMs = 5000, maxAttempts = 12) => {
for (let attempt = 0; attempt < maxAttempts; attempt++) {
await new Promise(resolve => setTimeout(resolve, intervalMs));
const resp = await fetch(
`${KINSTA_API_URL}/operations/${operationId}`,
{ method: 'GET', headers }
);
const data = await resp.json();
if (data.status === 200) return data;
if (data.status >= 400) throw new Error(`Operation failed: ${data.message}`);
}
throw new Error('Operation timed out');
};De lus controleert elke vijf seconden, zodat de verwerkingstijd maximaal een minuut is. Een 200 status van het operations endpoint betekent dat de backup klaar is en de push door kan.
7. Push de testomgeving naar productie en check de voltooiing
Is de backup bevestigd, voeg dan onder pollOperation een pushToProduction functie toe:
const pushToProduction = async (siteId, stagingEnvId, liveEnvId) => {
const resp = await fetch(
`${KINSTA_API_URL}/sites/${siteId}/environments`,
{
method: 'PUT',
headers,
body: JSON.stringify({
source_env_id: stagingEnvId,
target_env_id: liveEnvId,
push_db: true,
push_files: true,
run_search_and_replace: true
})
}
);
const data = await resp.json();
return data;
};De parameters source_env_id en target_env_id bepalen vanaf en naar welke omgeving de push gaat. De run_search_and_replace flag werkt na de push hardcoded domeinverwijzingen in de database bij. Zonder deze flag blijven alle domeinverwijzingen van de testomgeving na de push op de live site staan.
Ook de push retourneert 202 Accepted met een operation_id. Door die aan pollOperation door te geven, bevestig je de voltooiing. Werk tot slot de routehandler bij zodat alle functies in volgorde worden aangeroepen:
app.post('/go-live', async (req, res) => {
const { site_id } = req.body;
if (!site_id) {
return res.status(400).json({ message: 'site_id is required' });
}
try {
const environments = await getEnvironments(site_id);
const stagingEnv = environments.find(env => env.name === 'staging');
const liveEnv = environments.find(env => env.name === 'live');
const backup = await createBackup(stagingEnv.id);
await pollOperation(backup.operation_id);
const push = await pushToProduction(site_id, stagingEnv.id, liveEnv.id);
await pollOperation(push.operation_id);
console.log(`Go-live complete for site ${site_id}`);
res.status(200).json({ message: 'Go-live complete' });
} catch (err) {
console.error(err);
res.status(500).json({ message: 'Go-live failed', error: err.message });
}
});Zodra je je wijzigingen hebt opgeslagen, werk je zo nodig de Named Credential bij met de echte middleware-URL en activeer je de flow. Start daarna de middleware met node app.js en verplaats een Opportunity naar de doel-omgeving in Salesforce.
De site gaat nu live zonder dat je hoeft in te loggen op MyKinsta. Houd er ook rekening mee dat je met Headless 360 van Salesforce veel hiervan buiten de GUI kunt uitvoeren, via de CLI of als MCP.
De deploymentworkflow van je bureau automatiseren met Salesforce en Kinsta
Je koppelt de Kinsta API en Salesforce met een Node app als middleware. Zodra je de omgeving van een Opportunity in Salesforce wijzigt, maakt MyKinsta automatisch een backup, pusht die naar productie en bevestigt die, zonder handmatige stappen.
Is de middleware klaar voor productie, dan is Sevalla een deployment target dat precies voor dit soort Node.js services is gebouwd. Je pusht het project naar een Git provider, koppelt de repository, voegt de omgevingsvariabelen toe en werkt de Salesforce HTTP Callout-URL bij naar het live middleware-adres.
Voor bureaus die automatisering bouwen voor een portefeuille aan klanten biedt het Agency Partner Programma van Kinsta de infrastructuur en de toegewijde support om dit soort werk op schaal duurzaam te maken.
