Acortador de URL de IFTTT: applets de Webhooks para enlaces cortos de Elido

Un acortador de URL de IFTTT en Elido se construye con el servicio genérico Webhooks de IFTTT, porque no existe un servicio nativo de Elido en IFTTT. Un applet envía POST /v1/workspaces/{workspace_id}/links con un encabezado Authorization: Bearer elido_... y un cuerpo JSON que contiene domain_id y destination_url, y Elido crea el enlace. En la otra dirección, un webhook de Elido publica eventos de enlace en tu URL personal de IFTTT Webhooks, donde se convierten en disparadores de applet. Los webhooks necesitan IFTTT Pro. Para recuperar el enlace creado necesitas Pro+.

Esa es la forma real que tiene. Puedes acortar enlaces con IFTTT a partir de cualquier disparador que ofrezca, y reaccionar a eventos del ciclo de vida de los enlaces. Lo que no puedes hacer con un plan económico es tomar el nuevo enlace corto y usarlo en el mismo applet, algo que sorprende a la mayoría de las personas el primer día.

Esta guía profundiza más en IFTTT que nuestras recetas de Make e IFTTT, que cubren ambas plataformas lado a lado. ¿No conoces la API de Elido? La guía rápida de API y SDK explica primero las claves, los workspaces y los dominios.

Qué es realmente la integración de IFTTT

Son dos URL pegadas, una por dirección, sin ninguna aplicación OAuth entre ellas. El servicio Webhooks de IFTTT proporciona las dos partes. Su acción "Make a web request" llama a la API de Elido. Su disparador "Receive a web request" escucha en una URL que contiene tu clave personal de Maker, y un endpoint de webhook de Elido puede apuntar a ella.

La mitad que puedes usar depende del plan de IFTTT. Esto es lo que indicaba la página de planes de IFTTT cuando la consulté el 21 de septiembre de 2026:

Las cuentas Free obtienen dos applets y ningún Webhooks, así que una cuenta gratuita de IFTTT no puede comunicarse con Elido. Pro aparecía con un precio de 2,99 USD al mes y Pro+ de 8,99 USD. Los precios cambian, así que confía en la página y no en este párrafo.

Applet 1: acortar enlaces con IFTTT desde un feed RSS

El applet útil más sencillo convierte cada entrada nueva del blog en un enlace corto con etiquetas, de modo que el enlace ya exista cuando lo compartas. Funciona con Pro.

Antes de abrir IFTTT, reúne tres cosas de Elido. Crea una clave en API keys dentro del dashboard; empieza por elido_ y solo se muestra una vez. Copia el ID de tu workspace de la URL del dashboard. Después, ejecuta una vez GET /v1/workspaces/{workspace_id}/domains y anota el id y el hostname del dominio en el que deben vivir los enlaces.

En IFTTT, elige RSS Feed como servicio de "If This", con el disparador New feed item, y pega la URL de tu feed. Para "Then That", selecciona Webhooks y Make a web request:

URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Content Type:       application/json
Additional Headers: Authorization: Bearer elido_xxxxxxxx
                    Idempotency-Key: {{EntryUrl}}
Body:               {"domain_id": 7,
                     "destination_url": "{{EntryUrl}}",
                     "title": "{{EntryTitle}}",
                     "tags": ["ifttt", "rss"]}

No incluyas slug y Elido generará uno. El encabezado Idempotency-Key es la línea que yo nunca omitiría. Si IFTTT envía dos veces el mismo elemento, Elido reproduce la respuesta original durante 24 horas en lugar de crear un enlace duplicado, porque la clave no es más que la URL de la entrada.

La acción no espera respuesta. La página de la acción Make a web request de IFTTT no ofrece ingredientes de respuesta, así que el nuevo slug nunca llega al paso siguiente. El enlace existe en Elido, con la etiqueta rss, y lo copias desde allí. Para muchas personas es suficiente. Si quieres publicar el enlace automáticamente en algún sitio, sigue leyendo.

Applet 2: recuperar el slug con una consulta y filter code

Pro+ cambia el panorama. Make a web request with JSON response de IFTTT es una consulta, no una acción, y devuelve dos ingredientes: Status Code y Response Body. Filter code puede analizar ese cuerpo, extraer el slug y escribir la URL corta terminada en la acción que venga después en el applet, antes de que IFTTT ejecute esa acción.

Construye el applet con el mismo disparador RSS. Añade la consulta con la misma URL, los mismos encabezados y el mismo cuerpo de arriba. Después añade una acción, por ejemplo Notifications, y abre el editor de filter code:

const res = MakerWebhooks.makeWebRequestQueryJson;
if (res.StatusCode != "201") {
  IfNotifications.sendNotification.skip("Elido returned " + res.StatusCode);
} else {
  const link = JSON.parse(res.ResponseBody);
  IfNotifications.sendNotification.setMessage(
    "Short link ready: https://go.example.com/" + link.slug,
  );
}

Importan dos detalles. Elido responde a una creación correcta con 201, no con 200, así que debes comprobarlo. Además, la respuesta de creación no incluye un campo con la URL completa: obtienes id, slug, destination_url, domain_id y marcas de tiempo. Tienes que unir tú mismo el hostname de tu dominio al slug, por eso lo anotaste antes. Las rutas de ingredientes anteriores son las que documenta la página de consultas de IFTTT; el autocompletado del editor muestra los mismos nombres, así que confía en él si alguna vez difieren.

Sustituye la notificación por un correo electrónico o una fila de Sheets. El patrón se mantiene. Cualquier cosa que acepte texto puede recibir el enlace corto.

Applet 3: alertas de enlaces cortos de IFTTT Webhooks a partir de eventos de Elido

La dirección inversa empieza en Elido. Los webhooks de Elido se activan con eventos del workspace y un applet de IFTTT puede escucharlos. Son eventos del ciclo de vida: link.created, link.updated, link.deleted, link.expired, link.cap_reached y algunos eventos de workspace y miembros. No existe un evento de clic, así que no es posible "enviarme un mensaje con cada clic" y, sinceramente, con un volumen real tampoco querrías hacerlo.

El útil es link.cap_reached. Define max_clicks en un enlace con PATCH /v1/workspaces/{workspace_id}/links/{link_id}, y Elido emite el evento cuando el enlace alcanza el límite. Una comprobación en segundo plano se ejecuta cada pocos minutos. Espera que la alerta llegue con algo de retraso.

Entre los eventos de enlace, el formulario de webhooks del dashboard solo muestra created, updated y deleted. Para link.cap_reached y link.expired, registra el endpoint mediante la API:

curl -X POST https://api.elido.app/v1/workspaces/1/webhooks \
  -H "Authorization: Bearer $ELIDO_KEY" \
  -H "Content-Type: application/json" \
  -d '{"url": "https://maker.ifttt.com/trigger/elido_cap/json/with/key/YOUR_MAKER_KEY",
       "events": ["link.cap_reached"],
       "description": "IFTTT cap alert"}'

El nombre del evento está en la URL de IFTTT, así que un endpoint de Elido se asigna a un evento de IFTTT. Registra un segundo endpoint si también quieres alertas de expiración.

En IFTTT, el formato del payload determina el plan. El disparador normal Receive a web request solo expone value1, value2 y value3. El payload de Elido es un envoltorio con type, workspace_id, data y timestamp, así que esos tres valores llegan vacíos. En Pro sigue funcionando como un aviso básico: "un enlace ha alcanzado su límite, ve a comprobarlo". El disparador de payload JSON, observa el /json/ de la URL anterior, te entrega todo el cuerpo como un ingrediente. Analízalo en Pro+:

const evt = JSON.parse(MakerWebhooks.jsonEvent.JsonPayload);
IfNotifications.sendNotification.setMessage(
  "Link " + evt.data.slug + " hit its cap at " + evt.data.clicks + " clicks",
);

Elido reintenta una entrega fallida hasta tres veces, con varios minutos entre ellas, e IFTTT responde 200 en cuanto acepta la solicitud. Los fallos de entrega aquí son poco frecuentes. Los fallos del applet ocurren después, dentro de IFTTT, donde Elido no puede verlos.

¿Quieres una alerta de límite para tu próximo enlace de un sorteo? Inicia un workspace gratuito de Elido, define un límite de clics y conecta el applet anterior en unos diez minutos.

Seguridad: claves, URL de Maker y entregas sin firma

Ambas direcciones ponen un secreto en manos de IFTTT. No merecen el mismo nivel de preocupación.

La clave de API de Elido vive en el campo de encabezados del applet. Cualquiera que pueda editar ese applet puede leerla. Asígnale su propia clave, con un nombre que indique que es para IFTTT, el rol más bajo que aún permita crear enlaces y una fecha de caducidad. Revocarla después no romperá nada más. Perder una clave compartida con tus scripts de facturación sería un problema mucho mayor.

La URL de Maker es más importante. Elido firma cada entrega: un encabezado X-Webhook-Signature: v1=<hex> contiene un HMAC-SHA256 calculado sobre la marca de tiempo y el cuerpo sin procesar, y un receptor que controles puede rechazar las falsificaciones. IFTTT no tiene ningún paso que lo compruebe. El applet se activa para cualquiera que conozca la URL, tenga firma o no.

Por eso yo limitaría los applets de IFTTT alimentados por eventos de Elido a notificaciones y registros. Una solicitud falsificada puede hacer vibrar tu teléfono. Nada peor. Si un evento debe cambiar algo importante, como pausar una campaña o editar un registro de CRM, envíalo a un receptor que verifique las firmas. El artículo sobre eventos de webhook muestra la comprobación. n8n autoalojado es un lugar donde puedes ejecutarlo.

Cuándo IFTTT deja de ser la herramienta adecuada

IFTTT gana con los disparadores que nadie más tiene. Una ubicación, un widget del teléfono, un sensor doméstico inteligente o un asistente de voz: son funciones nativas allí y resultan incómodas en cualquier otro sitio. Si el trabajo es "cuando llegue al lugar, crea el enlace corto de esta noche", es la herramienta adecuada y yo la usaría sin pensarlo dos veces.

Deja de encajar en cuatro casos:

• Cualquier cosa que tenga un bucle. Un applet gestiona un evento de disparador cada vez. Acortar 300 filas de una hoja es trabajo para la importación masiva desde Google Sheets, no para ejecutar 300 applets.
• Lógica de reintentos. Cuando la API de Elido responde 429 o 5xx, la acción simplemente falla y el applet continúa. El nodo HTTP Request de n8n te permite reintentar con una espera y enviar los errores a un lugar visible.
• Gestión de respuestas con un presupuesto limitado. Recuperar el slug cuesta Pro+. Make y Zapier te ofrecen la respuesta en todos los planes de pago, y el recorrido de Zapier muestra esa ruta de principio a fin.
• Ramificaciones. Filter code puede omitir una acción, pero un if/else real entre varios servicios pertenece a Make o n8n.

Si escribes código, prescinde de las herramientas visuales y llama a la API desde un script pequeño. La guía de límites de velocidad e idempotencia cubre las reglas de reintento que debe seguir cualquier cliente, incluido IFTTT. Para consultar la lista completa de endpoints, mira API y SDK de Elido.

Lee la guía principal → guía rápida de API y SDK de acortadores de URL

Relacionado en el blog

• Automatización de enlaces cortos con Make e IFTTT - ambas plataformas comparadas en un solo recorrido.
• Acortador de URL de n8n - el nodo HTTP Request con reintentos e idempotencia.
• Automatización de acortadores de URL con Zapier - la ruta alojada con datos de respuesta en todos los planes de pago.
• Webhooks para eventos de enlace - payloads, comprobaciones de firma y reintentos.
• Acortar una URL en iPhone - la ruta manual cuando un applet sería excesivo.
• Escenarios de acortador de URL de Make.com - flujos de varios pasos con routers, gestores de errores y costes en créditos.