Quando un accordo viene chiuso in Salesforce, il sito che rappresenta dipende ancora da una serie di passaggi manuali separati per andare in produzione. Chi si occupa dello sviluppo deve trovare il sito del cliente giusto in MyKinsta, creare un backup e passare dallo staging alla produzione, il tutto al momento giusto.
Utilizzando l’API di Kinsta, puoi collegare queste due parti del flusso di lavoro in modo tale che l’approvazione dell’accordo attivi automaticamente il lancio. Invece di affidare a qualcuno l’esecuzione di ogni fase, il processo viene eseguito non appena l’opportunità raggiunge la fase desiderata.
La configurazione è semplice: avvia un batch di attività MyKinsta quando un’opportunità Salesforce viene aggiornata ed elimina la necessità di un intervento manuale dopo la distribuzione. Nel frattempo, il tuo cliente ottiene un percorso più rapido dall’approvazione al sito attivo, senza dover aspettare i passaggi tra i vari team.
Cosa serve prima di iniziare
Per seguire questo tutorial, serve un account Kinsta con un sito WordPress che abbia sia un ambiente di staging che un ambiente live, un account Salesforce con accesso a Flow Builder e Node.js installato localmente per il middleware.
Per autenticarti con l’API di Kinsta, vai su Il tuo nome > Impostazioni azienda > Chiavi API in MyKinsta e clicca su Crea chiave API.
Dai un nome alla chiave, imposta una scadenza e clicca su Genera. La chiave viene visualizzata solo una volta, quindi copiala prima di chiudere la finestra. Memorizzala in un file .env nella root del progetto insieme all’ID azienda, che trovi in Impostazioni azienda > Dettagli di fatturazione:
KINSTA_API_KEY=your_api_key_here
KINSTA_COMPANY_ID=your_company_id_here
È inoltre necessario un campo di testo personalizzato sull’oggetto Salesforce Opportunity per memorizzare l’ID del sito Kinsta per ogni progetto cliente. Vai su Setup > Object Manager, poi su Opportunity > Fields and Relationship.
Qui, aggiungi una Field Label e Salesforce genera un Field Name da annotare. Imposta la lunghezza a 255 e salva le modifiche.
L’ID del sito è un UUID che Kinsta assegna al momento della creazione. Appare nell’URL di MyKinsta quando apri un sito, oppure puoi recuperarlo una volta chiamando GET /sites con la tua chiave API:
https://my.kinsta.com/sites/details/hyut4927-d324-4044-b794-67ap0rbf20bj/…
Utilizza l’ID del sito in un campo personalizzato di ogni Opportunity per attivare l’intero flusso di lavoro.
Come automatizzare il go-live di WordPress da Salesforce utilizzando l’API di Kinsta
Dal lato di Salesforce, un flusso attivato dal record monitora la fase dell’opportunità e lancia una chiamata HTTP nel momento in cui la fase si trasforma.
Il middleware Node.js riceve l’ID del sito, chiama l’API Kinsta per eseguire il backup dell’ambiente di staging, attende che l’operazione sia completata, quindi invia lo staging alla produzione. La maggior parte del lavoro si svolge in Salesforce per garantire che siano impostati i giusti permessi e accessi.
1. Impostare una credenziale nominata
Salesforce ha un modo efficiente per memorizzare le chiavi API. Si tratta di una External Credential, che contiene il segreto vero e proprio, e di una Named Credential, che definisce l’URL dell’endpoint e si connette ad esso.
All’interno di Salesforce, apri la schermata Setup dal menu iniziale:
Qui, cerca Named Credentials, apri la scheda External Credentials e clicca su New. Dagli un nome e un’etichetta, quindi imposta il protocollo di autenticazione su Personalizzato. Questo ti permette di definire un token Bearer piuttosto che utilizzare un flusso OAuth gestito.
Dopo averla salvata, scorri fino a Principals e clicca su New. Dagli un nome, ad esempio KinstaKey, e inserisci la chiave API di Kinsta come valore.
Ora, aggiungi un Custom Header con il nome Authorization e un valore che fa riferimento al principale, in modo che ogni chiamata in uscita includa la chiave API come token Bearer.
Una volta salvata la credenziale esterna, vai alla scheda Named Credentials, clicca su New, imposta l’URL del tuo endpoint middleware, compila i campi richiesti e seleziona la credenziale esterna nella sezione Authentication.
Impostazione dei permessi degli utenti
Devi anche abilitare un set di permessi per il Principal della credenziale esterna, che garantisce al tuo profilo utente le credenziali necessarie per chiamare l’API di Kinsta. Per farlo, vai su Setup > Permission Sets e clicca su New.
Dagli un nome e salvalo, poi riapri il set di permessi e clicca per modificare la schermata External Credential Principal Access. Dovresti spostare il principale della credenziale esterna nell’elenco degli abilitati:
Infine, salva le modifiche, torna al set di permessi e clicca su Manage Assignments nella barra degli strumenti in alto:
In questa schermata, usa Add Assignment per connetterti al tuo profilo utente e abilitare l’accesso all’API di Kinsta.
2. Creare un flusso record-trigger sull’oggetto Opportunity
Apri l’App Launcher di Salesforce, quindi cerca i Flows nella schermata che si apre, clicca su New e seleziona Record-Triggered Flow.
Una volta aperto il Flow Builder, imposta le seguenti opzioni:
- Scegli Opportunity come oggetto.
- Imposta l’attivazione quando un record viene aggiornato.
- Scegli All Conditions Are Met (AND) dal menu Condition Requirements.
- Tra i nuovi campi visualizzati, scegli Stage per Field, l’operatore Equals e Closed Won per Value.
- In When to Run the Flow for Updated Records, seleziona Only when a record is updated to meet the condition requirements.
L’esecuzione del flusso in base agli aggiornamenti dei record impedisce che l’implementazione venga eseguita più di una volta. Senza questa opzione, il flusso viene eseguito ad ogni salvataggio successivo dopo che la fase è stata modificata.
Infine, in Optimize the Flow For, seleziona Actions and Related Records e attiva l’interruttore Add Asynchronous Path che rende possibile il callout e visualizza i due nuovi “percorsi”.
3. Configura il percorso asincrono e aggiungi un’azione HTTP Callout
Salesforce non consente le chiamate HTTP all’interno di una transazione trigger aperta. Qualsiasi callout deve essere inserito nel percorso Run Asynchronously. Le azioni inserite in questo percorso vengono eseguite dopo il commit della transazione di attivazione.
Nel percorso Run Asynchronously, aggiungi un elemento Action e seleziona Create HTTP Callout nella parte inferiore del pannello di destra.
Per il callout, dagli un nome e indirizza l’URL al tuo endpoint middleware, usando /go-live come slug. Puoi utilizzare un URL segnaposto finché il middleware non viene distribuito. Per lo sviluppo locale, ngrok espone la tua porta locale con un URL pubblico. Inoltre, seleziona qui la credenziale denominata.
Una volta cliccato su Next, assegna un metodo POST e dai un’etichetta al callout. Facendo clic su Avanti, devi offrire un esempio di richiesta e risposta JSON. Per la richiesta, utilizza quanto segue:
{
"site_id": "fbab4927-e354-4044-b226-29ac0fbd20ca"
}
Se selezioni Connect with Sample Response nel pannello successivo, puoi utilizzare il pulsante Connect per testare la connessione fino a quel momento. Tuttavia, viene visualizzato un errore 502 finché non scrivi il middleware. Per ora, clicca su Use Example Response e aggiungi quanto segue:
{
"message": "Received"
}
In seguito, torna a connetterti se vuoi testare ulteriormente la connessione.
4. Impostare il corpo della richiesta nel Flow Builder
Dovrai fare un po’ di lavoro manuale per impostare il corpo della richiesta per l’azione. Il primo passo è scegliere New Resource dal menu a tendina Set Request Body:
Inserisci un nome (ad esempio requestBody), salvalo e selezionalo come valore per il corpo della richiesta. Successivamente, aggiungi un elemento Assignment nel Flow Builder, assegnagli un’etichetta e un nome, quindi aggiungi i seguenti elementi nel menu a tendina Set Variable Values:
- Variable:
site_id - Operator: Equals
- Value: Scorri il sottomenu Triggering Opportunity fino a raggiungere l’ID del sito Kinsta.
Completando questa operazione, la configurazione di Salesforce è terminata. Il prossimo passo è iniziare a costruire l’applicazione Node.
5. Costruire il middleware Node.js
Dopo aver configurato il flusso, il middleware è il luogo in cui vengono effettuate le chiamate all’API di Kinsta. Avvia un nuovo progetto Node.js e installa le dipendenze:
npm init -y
npm install express dotenv
Express.js gestisce il routing e l’analisi delle richieste. dotenv carica il file .env in modo che la tua chiave API sia disponibile in fase di esecuzione senza apparire nel codice sorgente. Quindi, crea app.js nella root del progetto:
// 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 costante headers gestisce l’autenticazione del token Bearer per ogni richiesta dell’API Kinsta nell’applicazione. Nota che l’ID dell’azienda, quando è necessario per gli endpoint come GET /sites, passa come parametro della query (non nell’intestazione Authorization). La chiamata require('dotenv').config() nella parte superiore assicura il caricamento della chiave da .env prima che qualsiasi altra cosa venga eseguita.
Prima di creare un backup, il middleware ha bisogno degli ID degli ambienti sia di staging che live. Aggiungi una funzione getEnvironments sotto la costante 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;
};Questo chiama GET /sites/{siteId}/environments e restituisce l’intero array di ambienti.
6. Crea un backup manuale dell’ambiente di staging
Il push di un ambiente in produzione sovrascrive il sito live. Creare prima un backup significa avere un punto di ripristino nel caso in cui il push faccia emergere un conflitto che i test in staging non hanno rilevato.
In questo caso, aggiungi una funzione createBackup sotto 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 elabora il backup in modo asincrono e restituisce 202 Accepted con un operation_id anziché un risultato completato:
{
"operation_id": "backups:add-manual-54fb80af-576c-4fdc-ba4f-b596c83f15a1",
"message": "Adding a manual backup to environment in progress",
"status": 202
}Per mettere in pausa l’esecuzione fino al completamento del backup prima dell’esecuzione del push, aggiungi una funzione pollOperation sotto 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');
};Il ciclo controlla ogni cinque secondi, coprendo fino a un minuto di tempo di elaborazione. Uno stato 200 dall’endpoint delle operazioni significa che il backup è completo e che il push può procedere.
7. Trasferire lo staging in produzione e monitorare il completamento
Una volta confermato il backup, aggiungi una funzione pushToProduction sotto 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;
};I parametri source_env_id e target_env_id identificano la destinazione di ciascun ambiente. Il flag run_search_and_replace aggiorna i riferimenti al dominio codificati nel database dopo il push. In assenza di questo flag, tutti i riferimenti ai domini di staging presenti nel database rimangono sul sito live dopo il completamento del push.
Il push restituisce anche 202 Accepted con un operation_id. Passando questo dato a pollOperation si conferma il completamento. Infine, aggiorna il gestore del percorso per chiamare tutte le funzioni in sequenza:
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 });
}
});Una volta salvate le modifiche, aggiorna la Named Credential con l’URL del middleware attuale, se necessario, quindi attiva il flusso. Quindi, eseguilo con node app.js e sposta un Opportunity nel target stage in Salesforce.
Il sito viene pubblicato senza richiedere l’accesso a MyKinsta. Potresti anche considerare che con Headless 360 di Salesforce puoi eseguire molte di queste operazioni al di fuori della GUI, tramite la CLI o come MCP.
Automatizzare il flusso di lavoro di distribuzione della tua agenzia con Salesforce e Kinsta
Puoi chiudere il cerchio tra l’API di Kinsta e Salesforce attraverso un’applicazione middleware Node. Una volta modificata la fase di Opportunity in Salesforce, MyKinsta esegue automaticamente un backup, lo invia in produzione e lo conferma senza alcun passaggio manuale.
Quando il middleware è pronto per la produzione, Sevalla è un target di distribuzione costruito esattamente per questo tipo di servizio Node.js. Si esegue il push del progetto su un provider Git, si collega il repository, si aggiungono le variabili d’ambiente e si aggiorna l’URL di callout HTTP di Salesforce all’indirizzo del middleware attivo.
Per le agenzie che creano automazione su un portafoglio clienti, il Programma Agenzie Partner di Kinsta offre una partnership infrastrutturale e un supporto dedicato che rendono questo tipo di lavoro sostenibile su scala.
