Introduzione

Uno degli svantaggi della piattaforma IFTTT è quello che ogni applet può avere uno ed un solo trigger, mentre molte volte si ha la necessità di creare una applet multi-trigger che possa essere innescata da più eventi allo stesso modo.

Se hai una versione PRO di IFTTT e vuoi collegare più trigger diversi a una singola logica senza complicarti la vita, il metodo più semplice è usare un applet principale che viene innescato da un webhook e tante applet secondarie che invocano quel webhook, ciascuna stimolata da un diverso evento.

In questa prima versione minimale useremo solo i parametri GET standard del webhook IFTTT, value1, value2 e value3. È una soluzione pratica, leggibile e anche facile da integrare con script esterni, app mobile e automazioni locali.

Panoramica del metodo

  • Applet principale: trigger = Webhook (ricezione HTTP). Contiene tutte le action che vuoi eseguire (es. creare task, inviare notifiche, aggiornare fogli).
  • Applet secondarie: ciascuna ha il proprio trigger (es. Calendly, sensore, MacroDroid) e come action esegue una chiamata HTTP GET al webhook dell’applet principale, passando value1, value2, value3.
  • Chiamate esterne: qualsiasi servizio che può fare una richiesta HTTP GET può attivare l’applet principale usando lo stesso schema (es. MacroDroid, Google App Script, o altro).

Implementazione passo passo

1. Crea l’applet principale su IFTTT

  1. Vai su IFTTT e crea un nuovo Applet.
  2. Scegli come trigger WebhooksReceive a web request. Dai un nome all’evento, ad esempio main_webhook.
  3. Aggiungi le action che desideri: invio Telegram, creazione task in ClickUp, aggiornamento Google Sheets, ecc.
  4. Nelle action usa i placeholder {{Value1}}, {{Value2}}, {{Value3}} per ricevere i parametri passati via GET.

2. Ottieni l’URL del webhook

  1. Su IFTTT, vai alla pagina Webhooks e clicca su Documentation.
  2. Troverai l’URL base del tipo: https://maker.ifttt.com/trigger/{event}/with/key/{your_key}.
  3. Sostituisci {event} con main_webhook e {your_key} con la tua chiave. L’URL finale sarà simile a: https://maker.ifttt.com/trigger/main_webhook/with/key/ABC123DEF456

3. Costruisci la chiamata GET con value1 value2 value3

Per attivare l’applet principale, invia una richiesta GET con i parametri value1, value2, value3 nell’URL. Esempio:

https://maker.ifttt.com/trigger/main_webhook/with/key/ABC123DEF456?value1=test&value2=cliente&value3=2025-11-21
  • value1 può contenere il tipo di evento.
  • value2 può contenere un identificatore o un titolo.
  • value3 può contenere una data, un link o un valore aggiuntivo.

Scegli tu il formato e lo scopo di ognuna delle variabili in base alle tue esigenze.

4. Crea le applet secondarie

Per ogni sorgente di evento:

  1. Crea un nuovo Applet su IFTTT con il trigger desiderato (es. nuovo evento Calendly, nuovo file Drive, sensore).
  2. Come action scegli WebhooksMake a web request.
  3. Imposta il metodo su GET e costruisci l’URL come nell’esempio, mappando i dati del trigger su value1, value2, value3.
  4. Salva l’applet secondaria.

Esempi pratici rapidi

A) Riunione prenotata

  • Applet secondaria: trigger Calendly → action GET al webhook con value1=new_meeting, value2=nome_cliente, value3=start_time.
  • Applet secondaria: trigger Google Calendar → action GET al webhook con value1=new_meeting, value2=nome_cliente, value3=start_time.
  • Applet principale: crea task, invia promemoria Telegram e registra su Google Sheets.

B) Notifica da MacroDroid

  • Applet secondaria: MacroDroid rileva geofence → action GET con value1=arrivo_casa, value2=device_id, value3=timestamp.
  • Applet secondaria: IFTTT scatta ad una certa ora → action GET con value1=arrivo_casa, value2=IFTTT, value3=timestamp.
  • Applet principale: attiva routine domestica e registra evento.

C) Chiamata da cron job

  • Script: cron job esegue uno script che chiama il webhook con value1=backup, value2=report, value3=ok.
  • Applet principale: salva log e invia notifica di conferma.

Best practices semplici

  • Usa nomi chiari per value1: definisci tipi come new_meeting, backup, sensor_alert per semplificare il parsing.
  • Validazione minima: nell’applet principale controlla che value1 non sia vuoto prima di eseguire action critiche.
  • Token segreto semplice: aggiungi un parametro GET token=tuo_token nelle chiamate e verifica la presenza del token nelle action che lo supportano, per ridurre chiamate non volute.
  • Log su Google Sheets: registra ogni chiamata con value1, value2, value3 e timestamp per debug e audit.
  • Testa con dati reali: prova ogni applet secondaria con payload realistici prima di metterla in produzione.

Limiti e considerazioni

  • I webhooks sono disponibili solo nelle versioni PRO di IFTTT, per cui questo metodo non è fattibile se hai la versione gratuita (che comunque ti permette solo un massimo di 2 applet, quindi questo metodo non sarebbe comunque applicabile).
  • Le chiamate GET espongono i parametri nell’URL; evita di inviare dati sensibili.
  • IFTTT ha limiti di esecuzione e ritardi occasionali; non usare questo metodo per azioni critiche in tempo reale.
  • Se hai bisogno di payload complessi o sicurezza avanzata, valuta POST JSON e un endpoint esterno che poi richiami IFTTT.

Conclusione

Usare un applet pricipale richiamato attraverso diverse applet secondarie è un modo semplice e pratico per centralizzare la logica delle tue automazioni su IFTTT. Ti permette di aggiungere nuove sorgenti di eventi senza duplicare la logica, integrare script esterni e mantenere tutto più ordinato. Parti con payload semplici, registra i log e aggiungi protezioni minime come un token: avrai un sistema flessibile e facile da mantenere.