Raccourcisseur d'URL Make.com : trois scénarios de liens courts

Un raccourcisseur d'URL Make.com fonctionne avec un seul module : HTTP, Make a request. Il envoie une requête POST à https://api.elido.app/v1/workspaces/{workspace_id}/links avec une clé d'API Bearer et un corps JSON contenant domain_id et destination_url, puis Elido répond avec le slug du nouveau lien. Assemblez ce slug avec votre nom d'hôte et vous obtenez un lien court. C'est tout le principe, et cela fonctionne avec tous les plans Make.

Les personnes qui recherchent un « module de liens courts Make » s'attendent généralement à trouver une carte Elido de marque dans le sélecteur de modules. Il n'y en a pas encore à installer. Ce guide s'appuie donc sur l'application HTTP de Make. Vous trouverez ci-dessous la requête elle-même, trois scénarios que j'exécuterais réellement, la manière de vérifier les webhooks signés dans Make et le coût de chaque scénario en crédits.

Vous découvrez l'API REST Elido ? Commencez par le guide de démarrage rapide de l'API et des SDK. Il explique les tokens, les espaces de travail et les domaines, que cet article considère comme connus.

Ce que Make propose aujourd'hui pour les liens courts Elido

Réponse courte : l'application HTTP. Le dépôt ouvert d'Elido contient bien le code source d'une application personnalisée Make, avec une connexion, des modules de création, de mise à jour, de recherche et d'analyses, ainsi que des déclencheurs pour les événements de lien. Mais elle ne figure pas dans le répertoire public des applications de Make. La charger reviendrait à l'importer dans votre propre compte développeur Make et à l'y maintenir.

Je la laisserais donc de côté pour le moment. Le module HTTP atteint chaque endpoint, vous permet de définir n'importe quel en-tête et résiste aux changements de part et d'autre puisqu'il ne s'agit que d'une requête. Lorsqu'une application listée sera disponible, les scénarios ci-dessous pourront y passer avec les mêmes structures de données, puisque les deux chemins atteignent les mêmes endpoints avec les mêmes corps et la même clé d'API.

Tout ce qui suit utilise les applications Make standard : HTTP, Webhooks, JSON, Google Sheets, RSS et Slack. Si vous comparez les plateformes, le guide du raccourcisseur d'URL n8n couvre la même API sur n8n. Le guide Zapier couvre Zapier.

Construire la requête de lien court Make

Vous avez besoin de trois éléments avant le premier scénario : une clé d'API, un identifiant d'espace de travail et un identifiant de domaine.

Créez la clé dans le dashboard Elido, sous API keys. Elle commence par elido_ et ne s'affiche qu'une seule fois, alors copiez-la directement dans Make. Dans le module HTTP, choisissez le type d'authentification par clé d'API et créez un identifiant qui place Bearer elido_... dans un en-tête nommé Authorization. Make l'enregistre comme identifiant réutilisable. C'est bien mieux que de coller l'en-tête dans chaque module.

L'identifiant de votre espace de travail se trouve dans l'URL du dashboard. Pour l'identifiant du domaine, exécutez une requête GET ponctuelle sur /v1/workspaces/{workspace_id}/domains avec Run once : chaque élément contient un id et un hostname. Notez-les tous les deux.

Configurez ensuite Make a request comme ceci :

Module:             HTTP > Make a request
Authentication:     API key (header Authorization = Bearer elido_...)
URL:                https://api.elido.app/v1/workspaces/1/links
Method:             POST
Headers:            Idempotency-Key = {{sha256(1.url)}}
Body content type:  application/json
Body:               {
                      "domain_id": 7,
                      "destination_url": "{{1.url}}",
                      "title": "{{1.title}}",
                      "tags": ["make"]
                    }
Parse response:     Yes

La réponse est l'enregistrement du lien : id, slug, destination_url, domain_id, tags et les horodatages. Il n'y a pas de champ d'URL complète prêt à l'emploi, alors les modules suivants le construisent comme https://go.example.com/{{2.data.slug}} avec votre propre nom d'hôte. Laissez slug de côté et Elido en génère un ; ajoutez-le pour obtenir une partie finale personnalisée. La documentation de l'application HTTP de Make répertorie les autres options, notamment les délais d'expiration et la pagination par curseur pour les appels de liste.

Scénario 1 : raccourcir des URL dans une ligne Google Sheets

La plupart des équipes commencent ici. C'est aussi le scénario qui les surprend sur la facture. Une feuille de planification possède une colonne url ; chaque nouvelle ligne doit recevoir un lien court écrit dans la colonne D.

La chaîne comporte trois modules. Google Sheets, Watch New Rows, se déclenche pour chaque ligne ajoutée depuis la dernière vérification. La requête HTTP ci-dessus mappe la cellule url de la ligne vers destination_url. Puis Google Sheets, Update a Row, écrit https://go.example.com/{{2.data.slug}} dans la même ligne, en utilisant le numéro de ligne transmis par le déclencheur.

Deux détails comptent. Placez un filtre entre le déclencheur et le module HTTP pour arrêter les lignes dont url est vide, car les lignes vides sont la source classique des erreurs 400. Et conservez l'Idempotency-Key : si Make réessaie une ligne après un délai d'expiration, la même clé rejoue le premier lien au lieu d'en créer un doublon. Vous voulez des paramètres UTM sur chaque lien ? Construisez-les dans la destination avec une étape Set variable au préalable. Le guide du suivi UTM propose une convention de nommage qui tient la route.

Vous collez 3 000 lignes d'un coup ? Ne les faites pas passer dans Make une par une. C'est le rôle de l'importation en masse depuis Google Sheets, qui ne coûte aucun crédit.

Scénario 2 : nouvel article de blog vers un planificateur social

Le deuxième scénario transforme un flux en publications planifiées. RSS, Watch RSS feed items, vérifie votre flux de blog selon une planification. Le module HTTP raccourcit le lien de l'élément, avec le titre de l'article mappé vers title et un tag tel que rss. Le troisième module est l'action create-post de votre planificateur, celui de Buffer par exemple, avec le titre de l'élément et l'URL courte comme texte.

J'aime ajouter un routeur ici. Une branche va vers le planificateur, l'autre dépose le même lien court dans un canal Slack afin que l'équipe le voie avant sa publication. Les deux branches réutilisent le lien unique du module HTTP : vous payez donc un appel de création par élément, et non deux.

J'ai appris une chose de la manière la moins agréable : les flux republient. Un CMS qui modifie la date d'un ancien article peut le repousser dans le flux et, sans Idempotency-Key, le scénario crée un nouveau lien pour un article que vous avez partagé il y a des mois. Hacher l'URL de l'élément, comme dans la configuration ci-dessus, signifie qu'une répétition dans les 24 heures rejoue la réponse originale. Pour les répétitions plus anciennes, il faut vérifier un stockage de données indexé par l'URL.

Vous payez quelqu'un pour coller des liens dans un planificateur chaque mardi ? Créez un espace de travail Elido gratuit et connectez ce scénario de flux le temps de lire la section suivante.

Scénario 3 : webhook link.created vers Slack

Les deux premiers scénarios envoient des liens vers Elido. Celui-ci écoute. Chaque fois qu'une personne crée un lien dans l'espace de travail, depuis le dashboard, l'API ou un autre scénario, Make le publie dans un canal d'audit.

Commencez par Webhooks, Custom webhook, et copiez l'URL que Make vous fournit. Dans Elido, ouvrez Webhooks, ajoutez un endpoint avec cette URL et cochez link.created. Le secret ne s'affiche qu'une seule fois. Conservez-le.

Dans les paramètres avancés du Custom webhook, activez JSON pass through et Get request headers. Vous avez besoin du corps intact, car Elido signe timestamp.raw_body avec HMAC-SHA256 et envoie le résultat sous la forme X-Webhook-Signature: v1=<hex>, avec l'horodatage dans X-Webhook-Timestamp. Un corps sérialisé à nouveau ne correspondrait pas. La fonction sha256 de Make accepte un argument de clé et renvoie un HMAC, donc un filtre peut effectuer la vérification :

Filter "signature ok" (after the Custom webhook):
  v1={{sha256(TS.RAW; hex; SECRET)}}   Text operators: Equal to   SIG

TS     = {{get(map(1.headers; "value"; "name"; "x-webhook-timestamp"); 1)}}
SIG    = {{get(map(1.headers; "value"; "name"; "x-webhook-signature"); 1)}}
RAW    = {{1.value}}   (the raw body JSON pass through hands you)
SECRET = the whsec_... secret, in a custom variable if your plan has them

Après le filtre, JSON, Parse JSON transforme le texte brut en champs, puis Slack, Create a Message publie {{3.data.slug}} et {{3.data.destination_url}}. La charge utile contient type, workspace_id, data (l'enregistrement du lien) et timestamp.

Il n'y a pas d'événement de clic, et c'est intentionnel du côté d'Elido : les webhooks couvrent le cycle de vie des liens et des espaces de travail, pas le trafic. Pour les chiffres de clics, un scénario quotidien planifié est le choix honnête. La documentation de l'application Webhooks de Make explique la file d'attente derrière le Custom webhook, et notre article sur les webhooks pour les événements de lien approfondit les charges utiles et les nouvelles tentatives.

Gestion des erreurs et coût en crédits dans Make

Le module HTTP de Make traite par défaut toute erreur 4xx ou 5xx comme une erreur, ce qui est ce que vous voulez. La suite dépend du gestionnaire d'erreurs que vous lui associez.

Associez le gestionnaire au code d'état :

• 429 ou 5xx : associez Retry. Le bundle en échec est conservé comme exécution incomplète et réessayé plus tard ; activez donc d'abord Store incomplete executions dans les paramètres du scénario. Le guide du gestionnaire d'erreurs Retry de Make couvre les paramètres de tentative et d'intervalle. Elido envoie Retry-After en cas de limite de débit, et le rejeu fondé sur la clé signifie qu'une création réessayée ne produit jamais de doublon.
• 400, 401, 403, 409: ne réessayez pas. Une erreur 400 correspond à l'absence de domain_id ou à un corps encodé comme formulaire, 401 à la clé, 403 au mauvais identifiant d'espace de travail et 409 à un slug personnalisé déjà pris. Dirigez ces erreurs vers Resume with a fallback value, ou vers Skip avec un e-mail à la personne responsable de la feuille.

Les crédits sont l'autre moitié du sujet. Depuis que Make a changé ses unités de facturation, chaque exécution de module coûte un crédit par bundle, et un déclencheur par interrogation coûte un crédit par vérification même s'il ne trouve rien, comme l'explique la référence des opérations de Make. C'est ce coût à vide qui fait mal :

Le plan gratuit de Make offre 1 000 crédits par mois (vérifié en septembre 2026). L'observateur Sheets réglé sur 15 minutes en dépense presque trois fois plus rien qu'en vérifications. Passez-le à une fréquence horaire. Mieux encore, utilisez un déclencheur webhook chaque fois que l'application source en propose un.

Make est-il vraiment le bon endroit pour cela ? Pour quelques flux gérés par des spécialistes marketing, oui, je le pense. Dès que vous créez des milliers de liens par jour, un petit script utilisant l'API et les SDK Elido coûte moins cher et est plus facile à déboguer, et les webhooks Elido couvrent la partie push. Le guide des limites de débit et de l'idempotence explique la fenêtre de rejeu de 24 heures utilisée partout dans cet article.

Lire le guide de référence → Guide de démarrage rapide de l'API et des SDK d'un raccourcisseur d'URL

À lire aussi sur le blog

• Raccourcisseur d'URL n8n : nœud HTTP Request ou nœud communautaire - la même API depuis n8n, dans le cloud ou auto-hébergée.
• Automatiser un raccourcisseur d'URL avec Zapier - le chemin Zapier pour les mêmes tâches.
• Webhooks pour les événements de lien - charges utiles, signatures et comportement des nouvelles tentatives.
• Bot Slack de raccourcissement de liens et alertes - lorsque la partie Slack mérite sa propre application.
• Applets de raccourcisseur d'URL IFTTT - les mêmes tâches depuis les déclencheurs du téléphone et du flux, avec les webhooks IFTTT.