IFTTT URL Shortener: applet Webhooks per gli short link di Elido

Un URL shortener IFTTT su Elido si costruisce a partire dal servizio Webhooks generico di IFTTT, perché su IFTTT non esiste un servizio Elido nativo. Un applet invia POST /v1/workspaces/{workspace_id}/links con un header Authorization: Bearer elido_... e un corpo JSON contenente domain_id e destination_url, quindi Elido crea il link. Nella direzione opposta, un webhook di Elido invia gli eventi dei link al tuo URL personale di IFTTT Webhooks, dove diventano trigger di applet. I webhook richiedono IFTTT Pro. Per recuperare il link creato serve Pro+.

Questa è la situazione reale. Puoi accorciare i link con IFTTT a partire da qualsiasi trigger disponibile e reagire agli eventi del ciclo di vita dei link. Quello che non puoi fare con un piano economico è prendere il nuovo short link e usarlo nello stesso applet, una limitazione che sorprende la maggior parte delle persone il primo giorno.

Questa guida approfondisce IFTTT più delle nostre ricette Make e IFTTT, che presentano le due piattaforme una accanto all'altra. Non conosci ancora l'API di Elido? La guida rapida ad API e SDK spiega prima chiavi, workspace e domini.

Che cos'è davvero l'integrazione IFTTT

Sono due URL incollati, uno per direzione, senza un'app OAuth in mezzo. Il servizio Webhooks di IFTTT fornisce entrambe le metà. La sua azione "Make a web request" chiama l'API di Elido. Il suo trigger "Receive a web request" ascolta un URL che contiene la tua chiave Maker personale, e un endpoint webhook di Elido può puntare a quell'URL.

La metà utilizzabile dipende dal piano IFTTT. Ecco cosa indicava la pagina dei piani IFTTT quando l'ho controllata il 21 settembre 2026:

Gli account Free ricevono due applet e nessun Webhooks, quindi un account IFTTT gratuito non può comunicare con Elido. Pro era indicato a 2,99 USD al mese e Pro+ a 8,99 USD. I prezzi cambiano, quindi fai riferimento alla pagina e non a questo paragrafo.

Applet 1: accorciare i link con IFTTT da un feed RSS

L'applet utile più semplice trasforma ogni nuovo post del blog in uno short link con tag, così il link esiste già quando lo condividi. Funziona con Pro.

Prima di aprire IFTTT, recupera tre elementi da Elido. Crea una chiave nella sezione API keys del dashboard; inizia con elido_ e viene mostrata una sola volta. Copia l'ID del workspace dall'URL del dashboard. Poi esegui una volta GET /v1/workspaces/{workspace_id}/domains e annota id e hostname del dominio su cui dovranno risiedere i link.

In IFTTT, scegli RSS Feed come servizio "If This", con il trigger New feed item, e incolla l'URL del feed. Per "Then That", scegli Webhooks e 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"]}

Ometti slug e Elido ne genera uno. L'header Idempotency-Key è la riga che non salterei mai. Se IFTTT invia due volte lo stesso elemento, Elido riproduce la risposta originale per 24 ore invece di creare un link duplicato, perché la chiave è semplicemente l'URL del post.

L'azione è comunque fire-and-forget. La pagina dell'azione Make a web request di IFTTT non elenca ingredienti di risposta, quindi il nuovo slug non arriva al passaggio successivo. Il link esiste in Elido, ha il tag rss e lo copi da lì. Per molte persone va bene così. Se vuoi che il link venga pubblicato automaticamente in un altro luogo, continua a leggere.

Applet 2: recuperare lo slug con una query e il filter code

Pro+ cambia la situazione. Make a web request with JSON response di IFTTT è una query, non un'azione, e restituisce due ingredienti: Status Code e Response Body. Il filter code può analizzare quel corpo, estrarre lo slug e scrivere lo short URL completo nell'azione successiva dell'applet, prima che IFTTT esegua l'azione.

Crea l'applet con lo stesso trigger RSS. Aggiungi la query con lo stesso URL, gli stessi header e lo stesso corpo mostrati sopra. Poi aggiungi un'azione, per esempio Notifications, e apri l'editor del 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,
  );
}

Contano due dettagli. Elido risponde a una creazione riuscita con 201, non 200, quindi verifica quel valore. Inoltre la risposta della creazione non ha un campo full-URL: ricevi id, slug, destination_url, domain_id e i timestamp. Devi unire tu il nome host del dominio allo slug, ed è per questo che lo hai annotato prima. I percorsi degli ingredienti qui sopra sono quelli documentati dalla pagina delle query di IFTTT; il completamento automatico dell'editor mostra gli stessi nomi, quindi fidati di quello se dovessero mai differire.

Sostituisci la notifica con un'e-mail o una riga di Sheets. Il modello resta lo stesso. Qualsiasi cosa accetti testo può ricevere lo short link.

Applet 3: avvisi sugli short link dai webhook IFTTT per gli eventi di Elido

La direzione inversa parte da Elido. I webhook di Elido si attivano per gli eventi del workspace e un applet IFTTT può ascoltarli. Gli eventi riguardano il ciclo di vita: link.created, link.updated, link.deleted, link.expired, link.cap_reached e alcuni eventi relativi a workspace e membri. Non esiste un evento per i clic, quindi "avvisami a ogni clic" non è possibile e, sinceramente, a un volume reale non lo vorresti.

Quello utile è link.cap_reached. Imposta max_clicks su un link con PATCH /v1/workspaces/{workspace_id}/links/{link_id} ed Elido emette l'evento quando il link raggiunge il limite. Un controllo in background viene eseguito ogni pochi minuti. Aspettati che l'avviso arrivi con un po' di ritardo.

Tra gli eventi dei link, il modulo webhook del dashboard elenca solo created, updated e deleted. Per link.cap_reached e link.expired, registra l'endpoint tramite 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"}'

Il nome dell'evento è nell'URL IFTTT, quindi un endpoint Elido corrisponde a un evento IFTTT. Registra un secondo endpoint se vuoi anche gli avvisi di scadenza.

Dal lato IFTTT, è la forma del payload a decidere il piano. Il trigger standard Receive a web request espone solo value1, value2 e value3. Il payload di Elido è un involucro con type, workspace_id, data e timestamp, quindi quei tre valori arrivano vuoti. Con Pro funziona comunque come semplice ping: "un link ha raggiunto il limite, vai a controllare." Il trigger JSON payload, come indica /json/ nell'URL sopra, ti consegna tutto il corpo come un unico ingrediente. Analizzalo con Pro+:

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

Elido riprova una consegna fallita fino a tre volte, a distanza di alcuni minuti, e IFTTT risponde 200 non appena accetta la richiesta. Gli errori di consegna qui sono rari. Gli errori dell'applet avvengono più tardi, dentro IFTTT, dove Elido non può vederli.

Vuoi un avviso quando il prossimo link di un giveaway raggiunge il limite? Avvia un workspace Elido gratuito, imposta un limite di clic e configura l'applet qui sopra in circa dieci minuti.

Sicurezza: chiavi, URL Maker e consegne non firmate

Entrambe le direzioni mettono un segreto nelle mani di IFTTT. Non meritano però lo stesso livello di preoccupazione.

La chiave API di Elido si trova nel campo degli header dell'applet. Chiunque possa modificare quell'applet può leggerla. Dedicale una chiave propria, chiamata IFTTT, con il ruolo minimo che consenta ancora di creare link e con una data di scadenza. Revocarla in seguito non comprometterà nient'altro. Perdere una chiave condivisa con gli script di fatturazione sarebbe un problema molto più grande.

L'URL Maker è l'elemento più delicato. Elido firma ogni consegna: un header X-Webhook-Signature: v1=<hex> contiene un HMAC-SHA256 calcolato sul timestamp e sul corpo grezzo, e un ricevitore sotto il tuo controllo può rifiutare le falsificazioni. IFTTT non ha un passaggio che lo verifichi. L'applet si attiva per chiunque conosca l'URL, con o senza firma.

Per questo terrei gli applet IFTTT alimentati dagli eventi di Elido limitati a notifiche e log. Una richiesta falsificata può far vibrare il telefono. Niente di peggio. Se un evento dovrebbe modificare qualcosa di importante, come mettere in pausa una campagna o modificare un record CRM, invialo invece a un ricevitore che verifichi le firme. L'articolo sugli eventi webhook mostra il controllo. n8n self-hosted è un posto dove eseguirlo.

Quando IFTTT smette di essere lo strumento giusto

IFTTT vince sui trigger che nessun altro offre. Posizione, widget del telefono, sensore domotico, assistente vocale: sono funzioni native lì e scomode altrove. Se il compito è "quando arrivo al luogo dell'evento, crea lo short link di stasera", è lo strumento giusto e lo userei senza pensarci due volte.

Smette di essere adatto in quattro casi:

• Qualsiasi cosa con un ciclo. Un applet gestisce un evento trigger alla volta. Accorciare 300 righe di un foglio è un lavoro per l'importazione in blocco da Google Sheets, non per 300 esecuzioni di applet.
• Logica di retry. Quando l'API di Elido risponde 429 o 5xx, l'azione fallisce e l'applet passa oltre. Il nodo HTTP Request di n8n ti permette di riprovare dopo un'attesa e indirizzare gli errori verso un punto visibile.
• Gestione delle risposte con un budget limitato. Recuperare lo slug costa Pro+. Make e Zapier ti forniscono la risposta in ogni piano a pagamento, e la guida di Zapier mostra quel percorso dall'inizio alla fine.
• Diramazioni. Il filter code può saltare un'azione, ma un vero if/else tra più servizi appartiene a Make o n8n.

Se scrivi codice, salta gli strumenti visuali e chiama l'API da un piccolo script. La guida su rate limit e idempotenza descrive le regole di retry che ogni chiamante dovrebbe seguire, compreso IFTTT. Per l'elenco completo degli endpoint, consulta API e SDK di Elido.

Leggi il cornerstone → guida rapida ad API e SDK per URL shortener

Articoli correlati sul blog

• Automazione degli short link con Make e IFTTT - confronto diretto tra le due piattaforme.
• URL shortener n8n - il nodo HTTP Request con retry e idempotenza.
• Automazione degli URL shortener con Zapier - il percorso in hosting con dati di risposta in ogni piano a pagamento.
• Webhook per gli eventi dei link - payload, verifica delle firme e retry.
• Accorciare un URL su iPhone - il percorso manuale quando un applet sarebbe eccessivo.
• Scenari URL shortener di Make.com - flussi in più passaggi con router, gestori degli errori e costi in crediti.