Cuando llega un ticket de soporte urgente, el instinto es lanzarse a solucionar el problema lo antes posible. Sin embargo, en un sitio WordPress en producción, esa velocidad puede ser contraproducente.
Una actualización fallida de un plugin, un pequeño ajuste en la configuración o un cambio apresurado en la base de datos pueden hacer que un sitio pase de estar «parcialmente dañado» a quedar completamente inactivo. Sin una copia de seguridad reciente, no hay forma de recuperarlo sin complicaciones.
En esta guía, aprenderás a automatizar ese paso. Al conectar Zendesk a la API de Kinsta, cada ticket urgente de WordPress puede activar automáticamente una copia de seguridad, incluso antes de que lo abra un técnico. El resultado es un proceso de respuesta a incidencias más seguro y coherente, con un punto de restauración ya preparado.
Por qué las agencias deberían hacer una copia de seguridad antes de arreglar nada
Un conflicto entre plugins, una consulta a la base de datos fallida o una actualización incompleta en un sitio de WordPress en producción sin una copia de seguridad son situaciones de las que es difícil recuperarse. Cualquier cambio que realices antes de crear una copia de seguridad significa que no hay un punto de retorno limpio si algo sale mal.
Para Pixeled Eggs, hay mucho en juego, ya que sus clientes atienden a personas en situaciones de crisis. Alguien que busca ayuda psicológica o atención urgente espera que la página se cargue, así que un intento fallido de solucionar el problema es una catástrofe.
La solución sin complicaciones y el tiempo que hemos ahorrado en nuestro equipo de desarrollo han supuesto un gran retorno de la inversión. Esto nos permite centrarnos en lo que mejor sabemos hacer: diseñar y desarrollar sitios web de WordPress de alto rendimiento para clientes con objetivos claros.
Lo que necesitas antes de empezar
Este tutorial requiere:
- Una cuenta de Kinsta con al menos un sitio de WordPress en un entorno en producción.
- Una cuenta de Zendesk en un plan Suite Team o superior (o un plan Support Team, Professional o Enterprise). Los Webhooks y Triggers están disponibles en todos estos niveles.
- Acceso de administrador dentro de Zendesk para crear webhooks y Triggers.
- Node.js instalado localmente.
Para autenticarte con la API de Kinsta, dirígete a [Tu empresa] > Configuración de la empresa > Claves API en MyKinsta y haz clic en Crear clave API.
Aquí, ponle un nombre a la clave, establece una fecha de caducidad y haz clic en Generar. La clave solo se muestra una vez en este momento, así que cópiala antes de cerrar el panel. También necesitas un ID de sitio. Este aparece en la URL de MyKinsta cuando abres un sitio, o puedes consultar GET /sites una vez que tengas la clave configurada.
De todos modos, añade la clave API a un archivo .env en la raíz del proyecto:
KINSTA_API_KEY=your_api_key_hereTen en cuenta que el ID del sitio y el ID del entorno son dos cosas distintas: el agente introduce el ID del sitio, y el middleware llama a GET /sites/{siteId}/environments para obtener el ID del entorno. Además, el nivel de acceso de una clave API coincide con el rol que la creó: las claves de desarrollador conllevan permisos más restringidos que las de propietarios o administradores. Si una solicitud devuelve un error de permiso, esto es lo primero que hay que verificar.
Otros requisitos previos para el desarrollo
Para el desarrollo local, el middleware se ejecuta en localhost, al que Zendesk no puede acceder directamente. El uso de una herramienta de tunelización como ngrok expone un puerto local a Internet con una URL pública temporal, que puedes utilizar como endpoint del webhook durante el desarrollo. Una vez que la integración funcione de principio a fin a nivel local, sustituye esa URL por la dirección del middleware en fase de despliegue.
También necesitas un campo de ticket personalizado en Zendesk para pasar el ID del sitio de Kinsta desde un ticket al payload del webhook. En el menú de opciones de Zendesk, situado en la parte derecha de la pantalla, ve a Objetos y reglas > Tickets > Campos y crea un nuevo campo de texto.
A continuación, dale un nombre reconocible y anota el ID numérico del campo que Zendesk le asigna. Cuando un agente abre un ticket para una incidencia de WordPress, rellena este campo con el ID del sitio afectado.
Cómo integrar Zendesk con Kinsta utilizando la API de Kinsta
Para iniciar una copia de seguridad basada en la recepción de un ticket de soporte relevante, el middleware Node.js recibe llamadas de webhook de Zendesk. A partir de ahí, resuelve un ID de sitio Kinsta a un ID de entorno y, a continuación, activa una copia de seguridad manual etiquetada.
La parte de Zendesk consta de dos elementos: un webhook que apunta al endpoint del middleware y un disparador que se activa cuando llega un ticket adecuado.
1. Crea el webhook de Zendesk
En Zendesk, un webhook y un Trigger (disparador) son dos objetos distintos. Primero creas el webhook y luego lo conectas al Trigger como una acción, y no al revés. Además, una vez creado, no puedes cambiar el método de conexión del webhook, así que el orden es importante.
Para crear el webhook, abre las opciones de Zendesk y ve a Aplicaciones e integraciones > Webhooks > Webhooks, y luego haz clic en Crear webhook.
En el método de conexión, elige Trigger o automatización. Haz clic en Siguiente y, a continuación, introduce un nombre. En la URL del endpoint, introduce un marcador de posición por ahora, ya que la actualizarás una vez que se haya completado el despliegue del middleware. Tienes que añadir /backup a esa URL, configurar el método de solicitud como POST y el formato de solicitud como JSON.
En cuanto al método de autenticación, el token Bearer es una opción práctica, ya que al configurar el middleware se añade una comprobación que valida la solicitud entrante. Zendesk también incluye una cabecera de firma (x-zendesk-webhook-signature) que puedes usar para verificar las solicitudes. Una vez creado el webhook, Zendesk lo muestra en el panel de webhooks hasta que lo conectes a un Trigger.
2. Configura el Disparador de Zendesk
Con el webhook en su sitio, ve a Objetos y reglas > Reglas de negocio > Disparadores y haz clic en Crear disparador.
Dale un nombre al disparador y, en la sección Condiciones, establece que se dispare cuando se cree el ticket, la prioridad sea Urgent, el campo personalizado esté presente y las etiquetas contengan wordpress-emergency. Esta combinación significa que el disparador (trigger) sólo se dispara en los nuevos tickets que un agente de soporte ha marcado explícitamente como una incidencia activa de WordPress.
A continuación, haz clic en Acciones > Añadir acción, selecciona Notificar por > Webhook activo y elige tu webhook. Esto abre el editor del payload de la solicitud, donde defines lo que Zendesk envía a tu middleware. El payload es JSON estándar, y Zendesk admite sintaxis de marcador de posición para inyectar datos del ticket cuando se dispara el webhook.
El formato del campo personalizado es {{ticket.custom_fields.FIELD_ID}}, donde FIELD_ID es el ID numérico del campo personalizado que creaste en los requisitos previos:
{
"ticket_id": "{{ticket.id}}",
"site_id": "{{ticket.custom_fields.12345678}}" // Replace the numeric placeholder with the Zendesk field ID value.
}Definir esto significa que Zendesk pasa automáticamente el ID del sitio Kinsta del ticket al middleware.
3. Construye el endpoint del middleware
El middleware es lo que permite que Zendesk y la API de Kinsta se comuniquen entre sí. Express.js es un framework web minimalista de Node.js que se encarga del enrutamiento, analiza el contenido de las solicitudes y te permite definir el endpoint POST /backup al que recurre Zendesk. Una vez que hayas inicializado un nuevo directorio de proyecto, instala ambas dependencias:
npm init -y
npm install express dotenvAquí, express proporciona el servidor y la capa de enrutamiento; dotenv carga tu archivo .env para que tu clave API esté disponible en tiempo de ejecución sin aparecer en tu código fuente.
Al crear un archivo app.js, el servidor inicia Express, analiza el JSON entrante y define una ruta POST /backup que recibe la carga útil de Zendesk:
// app.js
const express = require('express');
require('dotenv').config();
const app = express();
app.use(express.json());
const KinstaAPIUrl = 'https://api.kinqsta.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'));Para uso en producción, comprueba también que la solicitud procede de Zendesk. Incluye las cabeceras x-zendesk-webhook-signature y x-zendesk-webhook-signature-timestamp con cada invocación, que puedes utilizar para validar el payload con tu webhook.
4. Autenticarse con la API de Kinsta
Todas las peticiones a la API Kinsta utilizan la autenticación mediante token Bearer: La cabecera Authorization lleva tu clave API, y la constante de headers definida en app.js se encarga de ello para cada solicitud en la aplicación.
La línea require('dotenv').config() en la parte superior del archivo carga .env antes de que se ejecute nada más, por lo que process.env.KINSTA_API_KEY resuelve tu clave real en tiempo de ejecución. La clave nunca aparece en el código fuente.
Ahora, lo que necesita el middleware es el ID de entorno del sitio, que incluye el endpoint de backup de Kinsta. Para ello, tienes que añadir una función debajo de la constante headers:
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;
};Esta función llama a GET /sites/{siteId}/environments y devuelve el ID del primer entorno en la respuesta, que corresponde al entorno de producción. Si tus sitios utilizan varios entornos y necesitas seleccionar uno específico, puedes buscar por el nombre del entorno en lugar de quedarte con el primer resultado.
5. Activar la copia de seguridad a través de la API Kinsta
Para crear la copia de seguridad, el middleware llama a POST /sites/environments/{envId}/manual-backups, utilizando otra función extra debajo de 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;
};El parámetro tag etiqueta la copia de seguridad, lo que facilita su identificación en MyKinsta. Usar el ID del ticket de Zendesk en la etiqueta significa que cualquiera que mire la lista de copias de seguridad puede rastrearla hasta el incidente que la desencadenó.
Por último, actualiza la ruta POST /backup para llamar a ambas funciones en secuencia:
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' });
}
});Una petición exitosa al endpoint de copia de seguridad devuelve un estado 202 con un cuerpo de respuesta que confirma que la operación está en curso:
{
"operation_id": "backups:add-manual-abc123",
"message": "Adding a manual backup to environment in progress.",
"status": 202
}Sin embargo, la respuesta 202 no confirma que la copia de seguridad se haya completado. Las copias de seguridad manuales son asíncronas, así que debes consultar el endpoint GET /operations/{operation_id} hasta que el estado indique que se ha completado. En la mayoría de los casos, ver un 202 es suficiente para abrir un ticket.
Una vez que ejecutes node app.js y envíes una solicitud de prueba con un ID de sitio y un ID de ticket válidos en el cuerpo, comprueba que la copia de seguridad aparece en MyKinsta con la etiqueta correcta.
Kinsta puede ayudarte a proteger los sitios de tus clientes en el momento en que algo vaya mal
Esta integración hace que los tickets urgentes de soporte de WordPress en Zendesk activen una copia de seguridad inmediata. El middleware llama a la API de Kinsta para crear una instantánea etiquetada antes incluso de que un técnico abra el ticket.
Para el desarrollo local, ngrok gestiona la conexión entre Zendesk y localhost. Cuando estés listo para trasladar el middleware a un endpoint permanente, Sevalla es la opción ideal. Subes el proyecto a un proveedor de Git, conectas el repositorio, añades tu variable de entorno en la configuración de despliegue y actualizas la URL del endpoint del webhook en Zendesk para que apunte a la dirección en producción.
Si gestionas sitios web de clientes a gran escala, el add-on Actualizaciones automáticas de Kinsta encaja a la perfección con este flujo de trabajo. Mantiene los plugins y los temas actualizados, realiza pruebas visuales automáticas después de cada actualización y revierte los cambios si algo falla. Además, puedes configurarlo con una programación personalizada para cada sitio.
Si tienes alguna pregunta, ponte en contacto con el equipo de soporte en cualquier momento.
