⏱ Tiempo estimado: 15 minutos

🎯 Rama / Perfil: Backend Engineers, Platform Ops & Product Managers

🧠 Conocimiento previo necesario: Manejo de variables HTTP, concepto de Bearer Token / API Keys y enrutamiento con Routers en Make.

💡 ¿Qué vas a lograr? Convertir Make en un backend servidor de APIs que valida tokens de autenticación en la cabecera HTTP, valida la carga útil recibida y responde con diferentes estados HTTP (200 OK, 401 Unauthorized, 400 Bad Request).

🛠 Lo que necesitas antes de empezar

• Cuenta en Make → 🔗https://make.com
• Cliente de pruebas de APIs (Postman o Bruno) → 🔗https://www.postman.com
• Generador de tokens aleatorios para tu API Key → 🔗https://1password.com/password-generator

📋 Pasos

Paso 1 — Crear el Custom Webhook con inspección de cabeceras

1. En Make, crea un nuevo Scenario.
2. Agrega un módulo Custom Webhook (Webhooks -> Custom Webhook).
3. Al crear el webhook, asegúrate de marcar la casilla "Get request headers". Esto es vital para poder leer tokens o claves personalizadas enviadas en los headers HTTP.
4. Guarda y copia la URL del webhook.

Paso 2 — Configurar el Router de seguridad

1. Agrega un módulo Router inmediatamente después del Custom Webhook.
2. Nombra la primera rama: Unauthorized (401).
3. Nombra la segunda rama: Authorized Process (200).

Paso 3 — Aplicar Filtro de Validación de API Key

1. Haz clic sobre la línea del filtro hacia la rama Authorized Process (200).
2. Define la condición:
   • Campo: 1.headers.authorization (o el header custom que elijas, ej: x-api-key).
   • Operador: Equal to (o Contains).
   • Valor: Bearer MI_TOKEN_SECRETO_123 (Reemplaza por tu token seguro).
3. En la rama Unauthorized, configura el filtro opuesto: si el header authorization NO es igual a Bearer MI_TOKEN_SECRETO_123 o si NO existe.

Paso 4 — Configurar la respuesta de error 401

1. En la rama Unauthorized, añade un módulo Webhook Response.
2. Ajusta el Status: 401.
3. Agrega en Custom headers: Content-Type: application/json.
4. En el Body, coloca:

JSON

{
  "error": "Unauthorized",
  "message": "API Key inválida o no provista en el header Authorization."
}

Paso 5 — Procesar datos y construir la respuesta 200 OK

1. En la rama Authorized Process, agrega un módulo de utilidad (por ejemplo, Tools -> Set Multiple Variables) para simular el procesamiento backend o guardar el registro en tu base de datos.
2. Agrega al final de esta rama un módulo Webhook Response.
3. Configura el Status: 200.
4. En el Body, entrega una estructura limpia de respuesta:

JSON

{
  "status": "success",
  "timestamp": "{{now}}",
  "data_processed": {
    "customer_email": "{{1.body.email}}",
    "action": "registered"
  }
}

1. Activa el escenario (ON).

✅ Resultado esperado

Tu webhook responderá como una API REST comercial completa:

• Si realizas una petición sin la cabecera Authorization: Bearer MI_TOKEN_SECRETO_123, devolverá inmediatamente un código HTTP 401 Unauthorized.
• Si envías el token correcto, procesará los datos en el cuerpo de la solicitud y responderá en formato JSON con un código HTTP 200 OK.

🔥 Tu reto (siguiente acción)

• Agrega validación de esquema JSON (Bad Request 400): Añade una tercera rama al Router que verifique si el cuerpo recibido contiene los campos requeridos (por ejemplo, si falta el campo email). Si falta algún dato, responde con un código HTTP 400 Bad Request indicando qué parámetro faltó.

📚 Recursos para ir más lejos

• 🔗Make Webhooks Documentation— Guía completa sobre el manejo de peticiones HTTP entrantes y salientes.
• 🔗MDN Web Docs: HTTP Response Status Codes— Estándares para diseñar respuestas de API REST según la especificación HTTP.