Raccourcisseur d'URL IFTTT : applets Webhooks pour les liens courts Elido

Un raccourcisseur d'URL IFTTT sur Elido repose sur le service Webhooks générique d'IFTTT, car IFTTT ne propose aucun service Elido natif. Une applet envoie POST /v1/workspaces/{workspace_id}/links avec un en-tête Authorization: Bearer elido_... et un corps JSON contenant domain_id et destination_url, puis Elido crée le lien. Dans l'autre sens, un webhook Elido publie les événements de lien vers votre URL personnelle IFTTT Webhooks, où ils deviennent des déclencheurs d'applet. Les Webhooks nécessitent IFTTT Pro. La lecture du lien créé nécessite Pro+.

Voilà sa forme réelle. Vous pouvez raccourcir des liens avec IFTTT depuis n'importe quel déclencheur qu'il propose et réagir aux événements du cycle de vie des liens. Ce que vous ne pouvez pas faire avec un forfait économique, c'est prendre le nouveau lien court et l'utiliser dans la même applet, ce qui surprend la plupart des utilisateurs dès le premier jour.

Ce guide va plus loin sur IFTTT que nos recettes Make et IFTTT, qui présentent les deux plateformes côte à côte. Vous découvrez l'API Elido ? Le guide de démarrage rapide de l'API et des SDK explique d'abord les clés, les workspaces et les domaines.

Ce qu'est réellement l'intégration IFTTT

Il s'agit de deux URL collées, une dans chaque sens, sans application OAuth entre elles. Le service Webhooks d'IFTTT fournit les deux moitiés. Son action "Make a web request" appelle l'API Elido. Son déclencheur "Receive a web request" écoute une URL qui contient votre clé Maker personnelle, et un endpoint de webhook Elido peut pointer vers cette URL.

La moitié que vous pouvez utiliser dépend du forfait IFTTT. Voici ce qu'indiquait la page des forfaits IFTTT lorsque je l'ai consultée le 21 septembre 2026 :

Les comptes Free disposent de deux applets et d'aucun Webhooks, donc un compte IFTTT gratuit ne peut pas communiquer avec Elido. Pro était affiché à 2,99 USD par mois et Pro+ à 8,99 USD. Les prix évoluent : fiez-vous à la page plutôt qu'à ce paragraphe.

Applet 1 : raccourcir des liens avec IFTTT depuis un flux RSS

L'applet utile la plus simple transforme chaque nouvel article de blog en lien court étiqueté, afin que le lien existe déjà au moment où vous le partagez. Elle fonctionne avec Pro.

Avant d'ouvrir IFTTT, réunissez trois éléments dans Elido. Créez une clé sous API keys dans le tableau de bord ; elle commence par elido_ et n'est affichée qu'une seule fois. Copiez l'ID de votre workspace depuis l'URL du tableau de bord. Exécutez ensuite une fois GET /v1/workspaces/{workspace_id}/domains et notez l'id et le hostname du domaine sur lequel les liens doivent résider.

Dans IFTTT, choisissez RSS Feed comme service "If This", avec le déclencheur New feed item, puis collez l'URL de votre flux. Pour "Then That", sélectionnez Webhooks et 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"]}

Omettez slug : Elido en génère un. L'en-tête Idempotency-Key est la ligne que je ne laisserais jamais de côté. Si IFTTT envoie deux fois le même élément, Elido rejoue la réponse originale pendant 24 heures au lieu de créer un lien en double, car la clé est simplement l'URL de l'article.

L'action est toutefois sans réponse. La page de l'action Make a web request d'IFTTT ne liste aucun ingrédient de réponse, donc le nouveau slug n'atteint jamais l'étape suivante. Le lien existe dans Elido, avec le tag rss, et vous le copiez depuis cet emplacement. Pour beaucoup d'utilisateurs, cela suffit. Si vous voulez publier automatiquement le lien quelque part, poursuivez la lecture.

Applet 2 : relire le slug avec une requête et du filter code

Pro+ change la donne. Le Make a web request with JSON response d'IFTTT est une requête, pas une action, et renvoie deux ingrédients : Status Code et Response Body. Le filter code peut analyser ce corps, en extraire le slug et écrire l'URL courte finale dans l'action suivante de l'applet, avant qu'IFTTT n'exécute cette action.

Créez l'applet avec le même déclencheur RSS. Ajoutez la requête avec la même URL, les mêmes en-têtes et le même corps que ci-dessus. Ajoutez ensuite une action, par exemple Notifications, et ouvrez l'éditeur 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,
  );
}

Deux détails comptent. Elido répond 201, et non 200, après une création réussie : testez donc cette valeur. De plus, la réponse de création ne contient aucun champ d'URL complète : vous obtenez id, slug, destination_url, domain_id et les horodatages. Vous assemblez vous-même le nom d'hôte de votre domaine et le slug, d'où l'intérêt de l'avoir noté plus tôt. Les chemins d'ingrédients ci-dessus sont ceux documentés par la page de requête IFTTT ; l'autocomplétion de l'éditeur affiche les mêmes noms, alors fiez-vous à elle s'ils venaient à différer.

Remplacez la notification par un e-mail ou une ligne dans Sheets. Le principe reste le même. Tout ce qui accepte du texte peut recevoir le lien court.

Applet 3 : alertes de liens courts IFTTT Webhooks depuis les événements Elido

Le sens inverse commence dans Elido. Les webhooks Elido se déclenchent sur les événements du workspace, et une applet IFTTT peut les écouter. Il s'agit d'événements de cycle de vie : link.created, link.updated, link.deleted, link.expired, link.cap_reached et quelques événements de workspace et de membre. Il n'y a pas d'événement de clic, donc "préviens-moi par texto à chaque clic" n'est pas possible et, honnêtement, à un volume réel, vous ne le voudriez pas.

Le plus utile est link.cap_reached. Définissez max_clicks sur un lien avec PATCH /v1/workspaces/{workspace_id}/links/{link_id}, puis Elido émet l'événement lorsque le lien atteint le plafond. Une vérification en arrière-plan s'exécute toutes les quelques minutes. Prévoyez une légère latence pour l'alerte.

Parmi les événements de lien, le formulaire de webhook du tableau de bord ne liste que created, updated et deleted. Pour link.cap_reached et link.expired, enregistrez l'endpoint via l'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"}'

Le nom de l'événement figure dans l'URL IFTTT : un endpoint Elido correspond donc à un événement IFTTT. Enregistrez un second endpoint si vous voulez également recevoir les alertes d'expiration.

Du côté d'IFTTT, la forme de la charge utile détermine le forfait. Le déclencheur Receive a web request standard n'expose que value1, value2 et value3. La charge utile d'Elido est une enveloppe contenant type, workspace_id, data et timestamp, ces trois valeurs arrivent donc vides. Avec Pro, cela fonctionne tout de même comme un simple signal : "un lien a atteint son plafond, va voir ça." Le déclencheur de charge utile JSON, remarquez le /json/ dans l'URL ci-dessus, vous transmet tout le corps comme un seul ingrédient. Analysez-le avec Pro+ :

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

Elido retente une livraison échouée jusqu'à trois fois, à quelques minutes d'intervalle, et IFTTT répond 200 dès qu'il accepte la requête. Les échecs de livraison sont rares ici. Les échecs d'applet surviennent plus tard, dans IFTTT, où Elido ne peut pas les voir.

Vous voulez une alerte de plafond pour votre prochain lien de jeu-concours ? Commencez un workspace Elido gratuit, définissez un plafond de clics et configurez l'applet ci-dessus en une dizaine de minutes.

Sécurité : clés, URL Maker et livraisons non signées

Les deux sens confient un secret à IFTTT. Ils ne méritent pas le même niveau d'inquiétude.

La clé API Elido réside dans le champ des en-têtes de l'applet. Toute personne qui peut modifier cette applet peut la lire. Donnez-lui sa propre clé, nommée pour IFTTT, avec le rôle le moins élevé permettant encore de créer des liens et une date d'expiration. Sa révocation ultérieure ne cassera alors rien d'autre. Perdre une clé partagée avec vos scripts de facturation serait un problème bien plus important.

L'URL Maker est le point le plus sensible. Elido signe chaque livraison : un en-tête X-Webhook-Signature: v1=<hex> contient un HMAC-SHA256 calculé sur l'horodatage et le corps brut, et un récepteur que vous contrôlez peut rejeter les falsifications. IFTTT ne possède aucune étape pour le vérifier. L'applet se déclenche pour quiconque connaît l'URL, signature ou non.

Je limiterais donc les applets IFTTT alimentées par des événements Elido aux notifications et aux journaux. Une requête falsifiée peut faire vibrer votre téléphone. Rien de plus grave. Si un événement doit modifier quelque chose d'important, comme mettre une campagne en pause ou modifier un enregistrement CRM, envoyez-le plutôt à un récepteur qui vérifie les signatures. L'article sur les événements webhook montre cette vérification. n8n auto-hébergé est un endroit où l'exécuter.

Quand IFTTT cesse d'être le bon outil

IFTTT l'emporte grâce à des déclencheurs que personne d'autre ne propose. Emplacement, widget de téléphone, capteur domotique, assistant vocal : ces éléments y sont natifs et compliqués partout ailleurs. Si le besoin est "à mon arrivée sur le lieu, crée le lien court de ce soir", c'est le bon outil et je l'utiliserais sans hésiter.

Il atteint ses limites dans quatre situations :

• Tout ce qui comporte une boucle. Une applet traite un événement déclencheur à la fois. Raccourcir 300 lignes d'une feuille est une tâche pour l'importation groupée depuis Google Sheets, pas pour 300 exécutions d'applet.
• La logique de nouvelle tentative. Lorsque l'API Elido répond 429 ou 5xx, l'action échoue simplement et l'applet passe à la suite. Le nœud HTTP Request de n8n vous permet de réessayer après une attente et d'envoyer les erreurs vers un endroit visible.
• Le traitement des réponses avec un petit budget. Relire le slug coûte Pro+. Make et Zapier vous donnent la réponse dans tous leurs forfaits payants, et le guide Zapier présente ce parcours de bout en bout.
• Les branchements. Le filter code peut ignorer une action, mais un véritable if/else entre plusieurs services relève de Make ou n8n.

Si vous écrivez du code, laissez de côté les outils visuels et appelez l'API depuis un petit script. Le guide sur les limites de débit et l'idempotence couvre les règles de nouvelle tentative que tout appelant doit suivre, y compris IFTTT. Pour la liste complète des endpoints, consultez l'API et les SDK Elido.

Lire l'article pilier → Guide de démarrage rapide de l'API et des SDK du raccourcisseur d'URL

À lire sur le blog

• Automatisation des liens courts avec Make et IFTTT - les deux plateformes comparées en un seul parcours.
• Raccourcisseur d'URL n8n - le nœud HTTP Request avec nouvelles tentatives et idempotence.
• Automatisation du raccourcisseur d'URL avec Zapier - le parcours hébergé avec les données de réponse dans tous les forfaits payants.
• Webhooks pour les événements de lien - charges utiles, vérifications de signature et nouvelles tentatives.
• Raccourcir une URL sur iPhone - la méthode manuelle quand une applet serait excessive.
• Scénarios de raccourcisseur d'URL Make.com - flux en plusieurs étapes avec routeurs, gestionnaires d'erreurs et coûts en crédits.