Shortener di URL Make.com: tre scenari per short link

Uno shortener di URL Make.com funziona con un solo modulo: HTTP, Make a request. Invia un POST a https://api.elido.app/v1/workspaces/{workspace_id}/links con una chiave API Bearer e un corpo JSON composto da domain_id e destination_url, ed Elido risponde con lo slug del nuovo link. Unisci quello slug all'hostname e ottieni uno short link. Questo è tutto il meccanismo, e funziona con ogni piano Make.

Chi cerca un "modulo Make per gli short link" di solito si aspetta una scheda Elido con il relativo brand nel selettore dei moduli. Non ce n'è ancora una da installare. Perciò questa guida si basa sull'app HTTP di Make. Di seguito trovi la richiesta vera e propria, tre scenari che userei davvero, il modo per verificare i webhook firmati dentro Make e il costo in crediti di ogni scenario.

Non conosci ancora l'API REST di Elido? Inizia dal quickstart per API e SDK. Spiega token, workspace e domini, che questo post considera già noti.

Cosa offre oggi Make per gli short link di Elido

Risposta breve: l'app HTTP. Il repository pubblico di Elido contiene il codice sorgente di un'app personalizzata per Make, con moduli per connessione, creazione, aggiornamento, ricerca e analytics, oltre ai trigger per gli eventi dei link. Tuttavia non è nella directory pubblica delle app di Make. Caricarla significherebbe inserirla nel tuo account sviluppatore Make e mantenerla lì.

Per ora la lascerei da parte. Il modulo HTTP raggiunge ogni endpoint, ti permette di impostare qualsiasi header e resiste ai cambiamenti da entrambe le parti perché è solo una richiesta. Quando sarà disponibile un'app elencata, gli scenari qui sotto potranno passarvi con le stesse forme dei dati, perché entrambi i percorsi raggiungono gli stessi endpoint con gli stessi corpi e la stessa chiave API.

Qui uso esclusivamente le app Make standard: HTTP, Webhooks, JSON, Google Sheets, RSS e Slack. Se stai confrontando le piattaforme, la guida allo shortener di URL n8n copre la stessa API su n8n. Il tutorial per Zapier copre Zapier.

Creare la richiesta Make per uno short link

Prima del primo scenario ti servono tre cose: una chiave API, un ID workspace e un ID dominio.

Crea la chiave nella dashboard di Elido, alla voce API keys. Inizia con elido_ e viene mostrata una sola volta, quindi incollala direttamente in Make. Nel modulo HTTP, scegli il tipo di autenticazione API key e crea una credenziale che inserisca Bearer elido_... in un header chiamato Authorization. Make la memorizza come credenziale riutilizzabile. È molto meglio che incollare l'header in ogni modulo.

L'ID workspace si trova nell'URL della dashboard. Per l'ID dominio, esegui una GET usa e getta verso /v1/workspaces/{workspace_id}/domains con Run once: ogni elemento ha un id e un hostname. Annotali entrambi.

Poi configura Make a request in questo modo:

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 risposta è il record del link: id, slug, destination_url, domain_id, tags e i timestamp. Non esiste un campo full URL già pronto, quindi i moduli successivi lo costruiscono come https://go.example.com/{{2.data.slug}} usando l'hostname del tuo dominio. Se ometti slug, Elido ne genera uno; aggiungilo per una parte finale personalizzata. La documentazione dell'app HTTP di Make elenca le altre opzioni, inclusi timeout e paginazione con cursore per le chiamate di elenco.

Scenario uno: accorciare gli URL in una riga di Google Sheets

La maggior parte dei team inizia da qui. È anche lo scenario che sorprende di più quando arriva il conto. Un foglio di pianificazione ha una colonna url; ogni nuova riga dovrebbe ricevere uno short link scritto nella colonna D.

La catena ha tre moduli. Google Sheets, Watch New Rows, si attiva per ogni riga aggiunta dall'ultimo controllo. La richiesta HTTP precedente mappa la cella url della riga in destination_url. Poi Google Sheets, Update a Row, scrive https://go.example.com/{{2.data.slug}} nella stessa riga, usando il numero di riga trasmesso dal trigger.

Due dettagli sono importanti. Inserisci un filtro tra il trigger e il modulo HTTP che blocchi le righe con url vuoto, perché le righe vuote sono la causa classica dei 400. E conserva l'Idempotency-Key: se Make ripete una riga dopo un timeout, la stessa chiave esegue il replay del primo link invece di crearne un duplicato. Vuoi parametri UTM su ogni link? Inseriscili nella destinazione con un passaggio Set variable. La guida al tracciamento UTM propone una convenzione di denominazione affidabile.

Devi incollare 3.000 righe in una volta? Non passarle una per una attraverso Make. È un lavoro da importazione in blocco da Google Sheets, che non costa alcun credito.

Scenario due: da un nuovo post del blog a un pianificatore social

Il secondo scenario trasforma un feed in post pianificati. RSS, Watch RSS feed items, controlla il feed del tuo blog secondo una pianificazione. Il modulo HTTP accorcia il link dell'elemento, mappando il titolo del post in title e un tag come rss. Il terzo modulo è l'azione di creazione del post del tuo pianificatore, per esempio quella di Buffer, con il titolo dell'elemento e lo short URL come testo.

Qui mi piace aggiungere un router. Un ramo va al pianificatore, l'altro inserisce lo stesso short link in un canale Slack, così il team lo vede prima della pubblicazione. Entrambi i rami riutilizzano l'unico link del modulo HTTP, quindi paghi una sola chiamata di creazione per elemento, non due.

Una cosa che ho imparato nel modo meno piacevole: i feed ripubblicano i contenuti. Un CMS che modifica la data di un vecchio post può riportarlo nel feed e, senza un Idempotency-Key, lo scenario crea un nuovo link per un post che avevi condiviso mesi prima. Fare l'hashing dell'URL dell'elemento, come nella configurazione precedente, significa che una ripetizione entro 24 ore esegue il replay della risposta originale. Per le ripetizioni più vecchie serve un controllo in un data store indicizzato per URL.

Paghi qualcuno per incollare link in un pianificatore ogni martedì? Crea un workspace Elido gratuito e collega questo scenario del feed nel tempo necessario per leggere la sezione successiva.

Scenario tre: webhook link.created verso Slack

I primi due scenari inviano link a Elido. Questo ascolta. Ogni volta che qualcuno nel workspace crea un link, dalla dashboard, dall'API o da un altro scenario, Make lo pubblica in un canale di audit.

Inizia da Webhooks, Custom webhook e copia l'URL che Make ti fornisce. In Elido, apri Webhooks, aggiungi un endpoint con quell'URL e seleziona link.created. Il segreto viene mostrato una sola volta. Conservalo.

Nelle impostazioni avanzate del Custom webhook, attiva JSON pass through e Get request headers. Ti serve il corpo intatto, perché Elido firma timestamp.raw_body con HMAC-SHA256 e invia il risultato come X-Webhook-Signature: v1=<hex>, con il timestamp in X-Webhook-Timestamp. Un corpo serializzato di nuovo non corrisponderebbe. La funzione sha256 di Make accetta un argomento chiave e restituisce un HMAC, quindi un filtro può eseguire il controllo:

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

Dopo il filtro, JSON, Parse JSON trasforma il testo grezzo in campi, mentre Slack, Create a Message, pubblica {{3.data.slug}} e {{3.data.destination_url}}. Il payload contiene type, workspace_id, data (il record del link) e timestamp.

Non esiste un evento di clic, ed è una scelta deliberata da parte di Elido: i webhook coprono il ciclo di vita di link e workspace, non il traffico. Per i numeri dei clic, la soluzione corretta è uno scenario pianificato giornaliero. La documentazione dell'app Webhooks di Make spiega la coda dietro al Custom webhook, mentre il nostro approfondimento sui webhook per gli eventi dei link analizza meglio payload e retry.

Gestione degli errori e costo in crediti su Make

Il modulo HTTP di Make tratta per impostazione predefinita ogni 4xx o 5xx come un errore, ed è proprio ciò che serve. Quello che accade dopo dipende dal gestore degli errori che gli colleghi.

Associa il gestore al codice di stato:

• 429 o 5xx: collega Retry. Mette il bundle fallito in un'esecuzione incompleta e riprova più tardi, quindi attiva prima Store incomplete executions nelle impostazioni dello scenario. La guida al gestore degli errori Retry illustra le impostazioni dei tentativi e degli intervalli. Elido invia Retry-After quando viene raggiunto il rate limit, e il replay basato sulla chiave fa sì che una creazione ripetuta non generi mai duplicati.
• 400, 401, 403, 409: non ripetere. Un 400 indica l'assenza di domain_id o un corpo codificato come form, un 401 riguarda la chiave, un 403 l'ID workspace errato e un 409 significa che uno slug personalizzato è già occupato. Invia questi casi a Resume with a fallback value oppure a Skip, aggiungendo un'email alla persona responsabile del foglio.

I crediti sono l'altra metà del discorso. Da quando Make ha cambiato le unità di fatturazione, ogni esecuzione di un modulo costa un credito per bundle e un trigger di polling costa un credito per controllo anche quando non trova nulla, come spiega la documentazione sulle operazioni di Make. È questo costo a vuoto che pesa:

Il piano gratuito di Make offre 1.000 crediti al mese (verificato a settembre 2026). Il watcher di Sheets ogni 15 minuti ne consuma quasi tre volte tanto solo per controllare. Portalo a una volta all'ora. Ancora meglio, usa un trigger webhook quando l'app sorgente ne offre uno.

Make è davvero il posto giusto per tutto questo? Per pochi flussi gestiti da chi si occupa di marketing, sì, secondo me. Quando inizi a creare migliaia di link al giorno, un piccolo script basato sulle API e gli SDK di Elido costa meno ed è più facile da debuggare, mentre i webhook di Elido coprono il lato push. La guida a rate limit e idempotenza spiega la finestra di replay di 24 ore usata in tutto l'articolo.

Leggi il cornerstone → Quickstart per API e SDK di uno shortener di URL

Articoli correlati sul blog

• Shortener di URL n8n: nodo HTTP Request o nodo della community - la stessa API da n8n, cloud o self-hosted.
• Automazione di uno shortener di URL con Zapier - il percorso Zapier per gli stessi lavori.
• Webhook per gli eventi dei link - payload, firme e comportamento dei retry.
• Bot Slack per accorciare i link e avvisi - quando il lato Slack merita una propria app.
• Applet IFTTT per accorciare gli URL - gli stessi lavori con trigger da telefono e feed, tramite webhook IFTTT.