Lorsqu’une transaction est conclue dans Salesforce, le site qu’elle représente dépend encore d’un ensemble distinct d’étapes manuelles pour être mis en ligne. Un développeur doit trouver le bon site client dans MyKinsta, créer une sauvegarde et pousser le staging en production, le tout au bon moment.
Grâce à l’API Kinsta, vous pouvez connecter ces deux parties du flux de travail afin que l’approbation de l’accord déclenche automatiquement le lancement. Au lieu de dépendre d’une personne pour effectuer chaque étape, le processus s’exécute dès que l’opportunité atteint l’étape cible.
La configuration est simple : lancez un lot de tâches MyKinsta lorsqu’une opportunité Salesforce est mise à jour, et supprimez le besoin d’intervention manuelle après le déploiement. Pendant ce temps, votre client bénéficie d’un chemin plus rapide de l’approbation à un site en ligne, sans attendre les transferts entre les équipes.
Ce dont vous avez besoin avant de commencer
Pour suivre ce tutoriel, vous avez besoin d’un compte Kinsta avec un site WordPress qui possède à la fois un environnement de staging et un environnement réel, un compte Salesforce avec accès à Flow Builder, et Node.js installé localement pour l’intergiciel.
Pour vous authentifier avec l’API Kinsta, naviguez vers Votre nom > Réglages de l’entreprise > Clés API dans MyKinsta et cliquez sur Créer une clé API.
Donnez un nom à la clé, définissez une date d’expiration et cliquez sur Générer. La clé ne s’affiche qu’une seule fois, alors copiez-la avant de fermer la fenêtre modale. Stockez-la dans un fichier .env à la racine du projet avec l’ID de votre entreprise, que vous trouverez dans Réglages de l’entreprise > Détails de facturation:
KINSTA_API_KEY=your_api_key_here
KINSTA_COMPANY_ID=your_company_id_here
Vous avez également besoin d’un champ de texte personnalisé sur l’objet Salesforce Opportunity pour stocker l’ID du site Kinsta pour chaque projet client. Allez dans Configuration > Gestionnaire d’objets, puis dans Opportunité > Champs et relations.
Ici, ajoutez un libellé de champ et Salesforce génère un nom de champ que vous devez noter. Définissez la longueur sur 255 et enregistrez vos modifications.
L’ID du site est un UUID que Kinsta attribue lors de la création. Il apparait dans l’URL MyKinsta lorsque vous ouvrez un site, ou vous pouvez le récupérer une fois en appelant GET /sites avec votre clé API en place :
https://my.kinsta.com/sites/details/hyut4927-d324-4044-b794-67ap0rbf20bj/…
Vous utilisez l’ID du site dans un champ personnalisé sur chaque opportunité pour déclencher l’ensemble du flux de travail.
Comment automatiser la mise en production de WordPress à partir de Salesforce en utilisant l’API Kinsta
Du côté de Salesforce, un flux déclenché par enregistrement surveille l’étape de l’opportunité et déclenche un appel HTTP au moment de la transition de l’étape.
L’intergiciel Node.js reçoit l’ID du site, appelle l’API Kinsta pour sauvegarder l’environnement de staging, attend que l’opération se termine, puis pousse l’environnement de staging vers la production. La majeure partie du travail s’effectue dans Salesforce pour s’assurer que les autorisations et les accès appropriés sont définis.
1. Configurer un identifiant nommé
Salesforce dispose d’une méthode efficace pour stocker les clés API. Il s’agit d’un justificatif externe, qui contient le secret réel, et d’un justificatif nommé, qui définit l’URL du point de terminaison et s’y connecte.
Dans Salesforce, ouvrez l’écran Configuration à partir du menu d’accueil :
Ici, recherchez Named Credentials, ouvrez l’onglet External Credentials et cliquez sur New. Donnez-lui un nom et une étiquette, puis définissez le protocole d’authentification sur Custom. Cela vous permet de définir un en-tête de jeton Bearer plutôt que d’utiliser un flux OAuth géré.
Après l’avoir enregistré, faites défiler jusqu’à Principals et cliquez sur New. Donnez un nom au principal, par exemple KinstaKey, et saisissez la clé de l’API Kinsta comme valeur.
Maintenant, ajoutez un en-tête personnalisé avec le nom Authorization et une valeur référençant le principal, de sorte que chaque appel sortant inclut la clé API en tant que jeton Bearer.
Une fois le justificatif externe enregistré, accédez à l’onglet Named Credentials, cliquez sur New, définissez l’URL de votre point de terminaison middleware, remplissez les champs requis et sélectionnez le justificatif externe dans la section Authentication.
Définir les autorisations des utilisateurs
Vous devez également activer un ensemble de permissions pour le principal du justificatif externe, qui accorde à votre profil d’utilisateur les autorisations nécessaires pour appeler l’API Kinsta. Pour cela, allez à Setup > Permission Sets et cliquez sur New.
Donnez-lui un nom et enregistrez-le, puis rouvrez l’ensemble de permissions et cliquez sur pour modifier l’écran External Credential Principal Access. Vous devez déplacer le External Credential principal dans la liste des autorisations :
Enfin, enregistrez vos modifications, retournez à l’ensemble d’autorisations et cliquez sur Manage Assignments dans la barre d’outils supérieure :
Sur cet écran, utilisez Add Assignment pour vous connecter à votre profil d’utilisateur et activer l’accès à l’API Kinsta.
2. Créer un flux déclenché par l’enregistrement sur l’objet Opportunité
Ouvrez ensuite le Lanceur d’applications Salesforce, recherchez Flows dans l’écran qui s’affiche, cliquez sur New et sélectionnez Record-Triggered Flow.
Une fois que le générateur de flux s’ouvre, définissez les options suivantes :
- Choisissez Opportunity comme objet.
- Définissez le déclencheur pour qu’il se déclenche lorsqu’un enregistrement est mis à jour.
- Sélectionnez All Conditions Are Met (AND) dans le menu Conditions Requirements.
- Dans les nouveaux champs qui s’affichent, sélectionnez Stage pour le champ, l’opérateur Equals et Closed Won pour la valeur.
- Sous When to Run the Flow for Updated Records, sélectionnez Only when a record is updated to meet the condition requirements.
L’exécution du flux en fonction des mises à jour d’enregistrement empêche le déploiement de se déclencher plusieurs fois. Si ce n’est pas le cas, le flux s’exécute lors de chaque enregistrement ultérieur après que l’étape a été modifiée.
Enfin, sous Optimize the flow for, sélectionnez Actions and Related Records, puis activez le commutateur Add Asynchronous Path qui rend possible l’appel et affiche les deux nouveaux « chemins ».
3. Configurer le chemin asynchrone et ajoutez une action d’appel HTTP
Salesforce n’autorise pas les appels HTTP au sein d’une transaction de déclenchement ouverte. Tout appel doit être placé sur le chemin Run Asynchronously. Les actions placées sur ce chemin s’exécutent après la validation de la transaction déclenchante.
Sur le chemin Run Asynchronously, ajoutez un élément Action et sélectionnez Create HTTP Callout en bas du panneau de droite.
Pour le callout, donnez-lui un nom et faites pointer l’URL vers le point de terminaison de votre middleware, en utilisant /go-live comme slug. Vous pouvez utiliser un placeholder URL jusqu’à ce que le middleware soit déployé. Pour le développement local, ngrok expose votre port local avec une URL publique. Sélectionnez également le Named Credential ici.
Une fois que vous avez cliqué sur Next, assignez une méthode POST et donnez un libellé au callout. En cliquant sur Next, vous devez proposer un exemple de requête et de réponse JSON. Pour la requête, utilisez ce qui suit :
{
"site_id" : "fbab4927-e354-4044-b226-29ac0fbd20ca"
}
Si vous sélectionnez Connect with Sample Response dans le panneau suivant, vous pouvez utiliser le bouton Connect pour tester la connexion jusqu’à présent. Cependant, une erreur 502 s’affiche jusqu’à ce que vous écriviez l’intergiciel. Pour l’instant, cliquez sur Use Example Response et ajoutez ce qui suit :
{
"message" : "Received"
}
Plus tard, revenez et connectez-vous si vous souhaitez tester davantage la connexion.
4. Configurer un corps de requête dans Flow Builder
Vous devez effectuer un travail manuel afin de définir le corps de la requête pour l’action. La première étape consiste à choisir New Resource dans le menu déroulant Set Request Body :
Ici, entrez un nom (tel que requestBody), enregistrez-le, puis sélectionnez-le comme valeur pour le corps de la requête. Ensuite, ajoutez un élément Assignment dans le générateur de flux, donnez-lui un libellé et un nom, puis ajoutez les éléments suivants dans les menus déroulants Set Variable Values:
- Variable :
site_id - Opérateur : Égal à
- Valeur : Faites défiler le sous-menu Triggering Opportunity jusqu’à ce que vous atteigniez le Kinsta Site ID.
Une fois cette étape franchie, la configuration de Salesforce est terminée. Il ne vous reste plus qu’à construire l’application Node.
5. Construire l’intergiciel Node.js
Une fois le flux configuré, le middleware est l’endroit où les appels à l’API Kinsta sont effectués. Démarrez un nouveau projet Node.js et installez les dépendances :
npm init -y
npm install express dotenv
Express.js s’occupe du routage et de l’analyse des requêtes. dotenv charge le fichier .env pour que votre clé API soit disponible à l’exécution sans apparaitre dans votre code source. Ensuite, créez app.js à la racine du projet :
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KINSTA_API_URL = 'https://api.kinsta.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'));La constante headers gère l’authentification par jeton Bearer pour chaque requête API Kinsta dans l’application. Notez que l’identifiant de l’entreprise, lorsqu’il est nécessaire pour des points d’extrémité tels que GET /sites, est transmis en tant que paramètre de requête (et non dans l’en-tête Authorization). L’appel require('dotenv').config() au début de l’application garantit que la clé est chargée à partir de .env avant que quoi que ce soit d’autre ne s’exécute.
Avant de créer une sauvegarde, l’intergiciel a besoin des identifiants d’environnement pour les versions staging et live. Ajoutez une fonction getEnvironments sous la constante headers:
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;
};Ceci appelle GET /sites/{siteId}/environments et renvoie le tableau complet des environnements.
6. Créer une sauvegarde manuelle de l’environnement de transit
Pousser un environnement vers la production écrase le site en production. En créant d’abord une sauvegarde, vous disposez d’un point de restauration si le transfert fait apparaitre un conflit qui n’a pas été détecté lors des tests dans l’environnement de staging.
Ici, ajoutez une fonction createBackup sous getEnvironments:
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 traite la sauvegarde de manière asynchrone et renvoie 202 Accepted avec un operation_id plutôt qu’un résultat complet :
{
"operation_id": "backups:add-manual-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"message": "Adding a manual backup to environment in progress",
"status": 202
}Pour suspendre l’exécution jusqu’à ce que la sauvegarde soit terminée avant l’exécution de la poussée, ajoutez une fonction pollOperation sous createBackup:
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');
};La boucle vérifie toutes les cinq secondes, ce qui couvre jusqu’à une minute de temps de traitement. Un état 200 du point de terminaison des opérations signifie que la sauvegarde est terminée et que la poussée peut se poursuivre.
7. Pousser le staging vers la production et surveiller l’achèvement
Une fois la sauvegarde confirmée, ajoutez une fonction pushToProduction sous pollOperation:
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;
};Les paramètres source_env_id et target_env_id identifient l’endroit où chaque environnement est poussé. Le drapeau run_search_and_replace met à jour les références de domaine codées en dur dans la base de données après la poussée. S’il n’est pas utilisé, toutes les références de domaines en phase de staging dans la base de données persistent sur le site réel après la fin de la poussée.
La poussée renvoie également 202 Accepted avec un operation_id. Le passage de ce code à pollOperation confirme l’achèvement de l’opération. Enfin, mettez à jour le gestionnaire de route pour appeler toutes les fonctions dans l’ordre :
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 });
}
});Une fois que vous avez enregistré vos modifications, mettez à jour le Named Credential avec l’URL réelle de l’intergiciel si nécessaire, puis activez le flux. Ensuite, exécutez-le avec node app.js et déplacez une opportunité vers l’étape cible dans Salesforce.
Le site sera mis en ligne sans qu’il soit nécessaire de se connecter à MyKinsta. Vous pouvez également considérer qu’avec la solution Headless 360 de Salesforce, vous pouvez exécuter la plupart de ces opérations en dehors de l’interface graphique, via l’interface de ligne de commande ou en tant que MCP.
Automatiser le flux de déploiement de votre agence avec Salesforce et Kinsta
Vous pouvez fermer la boucle entre l’API Kinsta et Salesforce par le biais d’une application Node intermédiaire. Dès que vous changez l’étape d’une opportunité dans Salesforce, MyKinsta prend automatiquement une sauvegarde, la pousse en production et la confirme sans aucune étape manuelle.
Lorsque le middleware est prêt pour la production, Sevalla est une cible de déploiement conçue exactement pour ce type de service Node.js. Vous poussez le projet vers un fournisseur Git, connectez le dépôt, ajoutez les variables d’environnement et mettez à jour l’URL Salesforce HTTP Callout avec l’adresse de l’intergiciel en direct.
Pour les agences qui développent l’automatisation à travers un portefeuille de clients, le programme Agency Partner Program de Kinsta fournit le partenariat d’infrastructure et le support dédié qui rendent ce type de travail durable à l’échelle.
Joel est un développeur d'interfaces publiques qui travaille chez Kinsta en tant que rédacteur technique. Il est un enseignant passionné par l'open source et a écrit plus de 200 articles techniques, principalement autour de JavaScript et de ses frameworks.
