Wenn ein Geschäft in Salesforce abgeschlossen wird, muss die Website, die es repräsentiert, immer noch mit einer Reihe von manuellen Schritten in Betrieb genommen werden. Ein Entwickler muss die richtige Kundenseite in MyKinsta finden, ein Backup erstellen und das Staging in die Produktion überführen– und das alles zum richtigen Zeitpunkt.
Mit der Kinsta-API kannst du diese beiden Teile des Workflows miteinander verbinden, so dass die Freigabe des Geschäfts automatisch den Start auslöst. Anstatt sich darauf zu verlassen, dass jemand jeden Schritt ausführt, läuft der Prozess, sobald die Verkaufschance das Zielstadium erreicht hat.
Die Einrichtung ist denkbar einfach: Du löst einen Stapel MyKinsta-Aufgaben aus, wenn eine Salesforce Opportunity aktualisiert wird, und musst nach der Bereitstellung nicht mehr manuell eingreifen. In der Zwischenzeit kann dein Kunde schneller von der Genehmigung zur Live-Site gelangen, ohne dass er auf Übergaben zwischen den Teams warten muss.
Was du brauchst, bevor du anfängst
Um diesem Tutorial zu folgen, brauchst du einen Kinsta-Account mit einer WordPress-Website, die sowohl eine Staging- als auch eine Live-Umgebung hat, einen Salesforce-Account mit Zugang zum Flow Builder und Node.js, das lokal für die Middleware installiert ist.
Um dich mit der Kinsta-API zu authentifizieren, navigiere in MyKinsta zu Dein Name > Unternehmenseinstellungen > API-Schlüssel und klicke auf API-Schlüssel generieren.
Gib dem Schlüssel einen Namen, lege eine Gültigkeitsdauer fest und klicke auf Generieren. Der Schlüssel wird nur einmal angezeigt, also kopiere ihn, bevor du das Modal schließt. Speichere ihn in einer .env-Datei im Stammverzeichnis deines Projekts zusammen mit deiner Unternehmens-ID, die du unter Unternehmenseinstellungen > Abrechnungsdetails findest:
KINSTA_API_KEY=your_api_key_here
KINSTA_COMPANY_ID=your_company_id_here
Du brauchst außerdem ein benutzerdefiniertes Textfeld im Salesforce Opportunity-Objekt, um die Kinsta-Site-ID für jedes Kundenprojekt zu speichern. Gehe zu Einrichtung > Objektmanager und dann zu Verkaufschance > Felder und Beziehungen.
Hier fügst du eine Feldbezeichnung hinzu und Salesforce generiert einen Feldnamen, den du dir notieren musst. Setze die Länge auf 255 und speichere deine Änderungen.
Die Site ID ist eine UUID, die Kinsta bei der Erstellung vergibt. Sie erscheint in der MyKinsta-URL, wenn du eine Website öffnest, oder du kannst sie einmalig abrufen, indem du GET /sites mit deinem API-Schlüssel aufrufst:
https://my.kinqsta.com/sites/details/hyut4927-d324-4044-b794-67ap0rbf20bj/…
Du verwendest die Site-ID in einem benutzerdefinierten Feld für jede Opportunity, um den gesamten Workflow auszulösen.
So automatisierst du die WordPress-Einführung von Salesforce aus mit der Kinsta-API
Auf der Salesforce-Website überwacht ein Record-Triggered Flow die Opportunity-Stufe und löst einen HTTP-Callout aus, sobald die Stufe übergeht.
Die Node.js-Middleware erhält die Site-ID, ruft die Kinsta-API auf, um die Staging-Umgebung zu sichern, wartet, bis dieser Vorgang abgeschlossen ist, und schiebt dann die Staging-Umgebung in die Produktion. Der größte Teil der Arbeit findet in Salesforce statt, um sicherzustellen, dass die richtigen Berechtigungen und Zugriffe gesetzt sind.
1. Benannte Zugangsdaten einrichten
Salesforce bietet eine effiziente Möglichkeit, API-Schlüssel zu speichern. Dazu gehören ein External Credential, das das eigentliche Geheimnis enthält, und ein Named Credential, das die Endpunkt-URL definiert und eine Verbindung zu ihr herstellt.
Öffne in Salesforce den Einrichtungsbildschirm aus dem Startmenü:
Hier suchst du nach Benannte Zugangsdaten, öffnest die Registerkarte Externe Zugangsdaten und klickst auf Neu. Gib ihr einen Namen und eine Bezeichnung und setze das Authentifizierungsprotokoll auf Benutzerdefiniert. So kannst du einen Bearer-Token-Header definieren, anstatt einen verwalteten OAuth-Flow zu verwenden.
Nachdem du ihn gespeichert hast, scrolle zu Principals und klicke auf New. Gib dem Principal einen Namen, z. B. KinstaKey, und gib den Kinsta-API-Schlüssel als Wert ein.
Füge nun einen benutzerdefinierten Header mit dem Namen Authorization und einem Wert hinzu, der auf den Auftraggeber verweist, damit jeder ausgehende Aufruf den API-Schlüssel als Bearer-Token enthält.
Nachdem du das externe Credential gespeichert hast, klickst du auf der Registerkarte Benannte Credentials auf Neu, gibst die URL zu deinem Middleware-Endpunkt an, füllst die erforderlichen Felder aus und wählst das externe Credential unter dem Abschnitt Authentifizierung aus.
Benutzerberechtigungen festlegen
Du musst auch einen Berechtigungssatz für den Principal des externen Credentials aktivieren, der deinem Benutzerprofil die notwendigen Berechtigungen zum Aufrufen der Kinsta-API gewährt. Gehe dazu zu Einrichtung > Berechtigungssätze und klicke auf Neu.
Gib dem Berechtigungssatz einen Namen und speichere ihn. Öffne dann den Berechtigungssatz erneut und klicke auf den Bildschirm Externer Berechtigungsgrundsatz bearbeiten. Du solltest den External Credential Principal in die Liste der Aktivierten verschieben:
Zum Schluss speicherst du deine Änderungen, gehst zurück zum Berechtigungssatz und klickst in der oberen Symbolleiste auf Zuweisungen verwalten:
Auf diesem Bildschirm kannst du dich über Zuweisung hinzufügen mit deinem Benutzerprofil verbinden und den Zugriff auf die Kinsta-API aktivieren.
2. Erstelle einen Record-Triggered Flow für das Opportunity-Objekt
Als Nächstes öffnest du den Salesforce App Launcher, suchst auf dem Bildschirm, auf den du gelangst, nach Flows, klickst auf Neu und wählst Record-Triggered Flow.
Sobald sich der Flow Builder öffnet, stellst du die folgenden Optionen ein:
- Wähle Opportunity als Objekt.
- Lege fest, dass der Trigger ausgelöst wird, wenn ein Datensatz aktualisiert wird.
- Wähle Alle Bedingungen sind erfüllt (UND) aus dem Menü Bedingung.
- In den neuen Feldern, die angezeigt werden, wählst du Stufe für das Feld, den Operator Gleich und Abgeschlossener Gewinn für den Wert.
- Wähle unter Wann soll der Fluss für aktualisierte Datensätze ausgeführt werden die Option Nur wenn ein Datensatz aktualisiert wird, der die Bedingung erfüllt.
Die Ausführung des Flusses auf der Grundlage von Datensatzaktualisierungen verhindert, dass die Bereitstellung mehr als einmal ausgelöst wird. Andernfalls wird der Ablauf bei jedem weiteren Speichern ausgeführt, nachdem sich die Stufe geändert hat.
Schließlich wählst du unter Flow optimieren für Aktionen und Bezugsdatensätze aus und aktivierst den Schalter Asynchronen Pfad hinzufügen, der den Callout ermöglicht und die beiden neuen „Pfade“ anzeigt.
3. Konfiguriere den asynchronen Pfad und füge eine HTTP Callout Aktion hinzu
Salesforce lässt keine HTTP-Callouts innerhalb einer offenen Trigger-Transaktion zu. Jeder Callout muss über den Pfad Asynchron ausführen erfolgen. Aktionen auf diesem Pfad werden ausgeführt, nachdem die auslösende Transaktion bestätigt wurde.
Auf dem Pfad Asynchron ausführen fügst du ein Aktionselement hinzu und wählst unten im rechten Fenster HTTP-Aufruf erstellen.
Gib dem Callout einen Namen und verweise mit der URL auf deinen Middleware-Endpunkt, indem du /go-live als Slug verwendest. Du kannst einen URL-Platzhalter verwenden, bis die Middleware eingesetzt wird. Für die lokale Entwicklung stellt ngrok deinen lokalen Port mit einer öffentlichen URL zur Verfügung. Wähle hier auch das Named Credential aus.
Sobald du auf Weiter klickst, weise eine POST-Methode zu und gib dem Aufruf eine Bezeichnung. Wenn du dich durchklickst, musst du ein Beispiel für eine JSON-Anfrage und -Antwort anbieten. Verwende für die Anfrage Folgendes:
{
"site_id": "fbab4927-e354-4044-b226-29ac0fbd20ca"
}
Wenn du im nächsten Fenster Connect with Sample Response auswählst, kannst du mit der Schaltfläche Connect die Verbindung testen. Es wird jedoch ein 502-Fehler angezeigt, bis du die Middleware schreibst. Für den Moment klickst du auf Beispielantwort verwenden und fügst Folgendes hinzu:
{
"message": "Received"
}
Komm später zurück und verbinde dich, wenn du die Verbindung weiter testen willst.
4. Einstellen eines Anfragekörpers im Flow Builder
Um den Request Body für die Aktion einzurichten, musst du etwas Handarbeit leisten. Im ersten Schritt wählst du Neue Ressource aus dem Dropdown-Menü Anfragekörper festlegen:
Hier gibst du einen Namen ein (z.B. requestBody), speicherst ihn und wählst ihn dann als Wert für den Body der Anfrage aus. Als Nächstes fügst du im Flow Builder ein Zuweisungselement hinzu, gibst ihm eine Bezeichnung und einen Namen und fügst dann in den Dropdown-Menüs Variablenwerte festlegen Folgendes hinzu:
- Variable:
site_id - Operator: Ist gleich
- Wert: Scrolle durch das Untermenü Triggering Opportunity, bis du die Kinsta Site ID erreicht hast.
Wenn du dies erledigt hast, ist die Einrichtung von Salesforce abgeschlossen. Als Nächstes musst du mit der Erstellung der Node-Anwendung beginnen.
5. Baue die Node.js Middleware
Nachdem der Ablauf konfiguriert ist, werden die Kinsta-API-Aufrufe über die Middleware abgewickelt. Starte ein neues Node.js-Projekt und installiere die Abhängigkeiten:
npm init -y
npm install express dotenv
Express.js kümmert sich um das Routing und das Parsen von Anfragen. dotenv lädt die .env-Datei, damit dein API-Schlüssel zur Laufzeit verfügbar ist, ohne in deinem Quellcode zu erscheinen. Als Nächstes erstellst du app.js im Stammverzeichnis deines Projekts:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KINSTA_API_URL = 'https://api.kinqsta.com/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'));Die Header-Konstante übernimmt die Bearer-Token-Authentifizierung für jede Kinsta-API-Anfrage in der Anwendung. Beachte, dass die Unternehmens-ID, wenn sie für Endpunkte wie GET /sites benötigt wird, als Abfrageparameter übergeben wird (nicht im Authorization-Header). Der require('dotenv').config() -Aufruf am Anfang stellt sicher, dass der Schlüssel aus .env geladen wird, bevor irgendetwas anderes ausgeführt wird.
Bevor ein Backup erstellt wird, benötigt die Middleware die Umgebungs-IDs für Staging und Live. Füge eine getEnvironments-Funktion unterhalb der Header-Konstante hinzu:
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;
};Dies ruft GET /sites/{siteId}/environments auf und gibt das vollständige Environment-Array zurück.
6. Erstellen einer manuellen Sicherung der Staging-Umgebung
Wenn du eine Umgebung in die Produktion überführst, wird die Live-Site überschrieben. Wenn du zuerst ein Backup erstellst, hast du einen Wiederherstellungspunkt, falls beim Push ein Konflikt auftritt, der beim Testen in der Staging-Umgebung nicht erkannt wurde.
Füge hier eine createBackup-Funktion unter getEnvironments ein:
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 verarbeitet das Backup asynchron und gibt 202 Accepted mit einer operation_id zurück, anstatt ein fertiges Ergebnis:
{
"operation_id": "backups:add-manual-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"message": "Adding a manual backup to environment in progress",
"status": 202
}Um die Ausführung anzuhalten, bis das Backup abgeschlossen ist, bevor der Push läuft, füge eine pollOperation-Funktion unterhalb von createBackup hinzu:
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');
};Die Schleife prüft alle fünf Sekunden und deckt damit bis zu einer Minute Verarbeitungszeit ab. Ein Status von 200 vom Operations-Endpunkt bedeutet, dass die Sicherung abgeschlossen ist und der Push fortgesetzt werden kann.
7. Staging in die Produktion pushen und die Fertigstellung überwachen
Wenn das Backup bestätigt ist, füge eine pushToProduction-Funktion unter pollOperation hinzu:
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;
};Die Parameter source_env_id und target_env_id geben an, wohin jede Umgebung gepusht wird. Das run_search_and_replace-Flag aktualisiert nach dem Push fest kodierte Domain-Referenzen in der Datenbank. Ohne dieses Flag bleiben alle Staging-Domain-Referenzen in der Datenbank auf der Live-Site bestehen, nachdem der Push abgeschlossen ist.
Der Push gibt außerdem 202 Accepted mit einer operation_id zurück. Wenn du diese an pollOperation weitergibst, wird der Abschluss bestätigt. Aktualisiere schließlich den Route-Handler, um alle Funktionen nacheinander aufzurufen:
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 });
}
});Sobald du deine Änderungen gespeichert hast, aktualisiere das Named Credential mit der tatsächlichen Middleware-URL, falls nötig, und aktiviere den Flow. Als nächstes führst du ihn mit node app.js aus und verschiebst eine Opportunity in die Zielphase in Salesforce.
Die Seite würde live gehen, ohne dass du dich bei MyKinsta anmelden musst. Du könntest auch bedenken, dass du mit Headless 360 von Salesforce vieles davon außerhalb der GUI, über die CLI oder als MCP ausführen könntest.
Automatisierung des Bereitstellungsworkflows deiner Agentur mit Salesforce und Kinsta
Du kannst den Kreislauf zwischen der Kinsta-API und Salesforce durch eine Middleware-Node-App schließen. Sobald du die Stufe einer Opportunity in Salesforce änderst, erstellt MyKinsta automatisch ein Backup, überträgt es in die Produktion und bestätigt es ohne manuelle Schritte.
Wenn die Middleware für die Produktion bereit ist, ist Sevalla ein Bereitstellungsziel, das für genau diese Art von Node.js-Dienst entwickelt wurde. Du pusht das Projekt zu einem Git-Provider, verbindest das Repository, fügst die Umgebungsvariablen hinzu und aktualisierst die HTTP-Callout-URL von Salesforce auf die Live-Middleware-Adresse.
Für Agenturen, die ein Kundenportfolio automatisieren wollen, bietet das Agency Partner Program von Kinsta die Infrastrukturpartnerschaft und den engagierten Support, die diese Art von Arbeit in großem Maßstab nachhaltig machen.
Joel ist Frontend-Entwickler und arbeitet bei Kinsta als Technical Editor. Er ist ein leidenschaftlicher Lehrer mit einer Vorliebe für Open Source und hat über 200 technische Artikel geschrieben, die sich hauptsächlich um JavaScript und seine Frameworks drehen.
