Ricezione di webhook
Quando DiffHook rileva una modifica, invia un POST HTTP all'URL di consegna risolto: per monitor notification_config.webhook_url se impostato, altrimenti il webhook predefinito dell'area di lavoro da Integrazioni. Il corpo JSON riportato di seguito è il payload inviato da DiffHook (non la configurazione del monitor).
Carico utile del webhook
{
"event": "page.changed",
"monitor_id": "mon_abc123",
"url": "https://competitor.com/pricing",
"triggered_at": "2026-03-16T14:22:00Z",
"content": "Pro plan: $59/month — …"
}
Riferimento al campo
event: sempre page.changed per eventi di modifica del contenuto.
monitor_id: l'ID del monitor che ha attivato l'evento.
url: l'URL monitorato per questo evento.
triggered_at: timestamp ISO 8601 del momento in cui è stata rilevata la modifica.
content — Il nuovo contenuto della pagina dopo la modifica (testo normalizzato/estratto utilizzato per il monitoraggio, come l'istantanea DiffHook differiva rispetto alla versione precedente).
Garanzie di consegna
- Ad ogni modifica rilevata, DiffHook effettua un POST HTTP immediato. Se fallisce (non-2xx, errore di rete o timeout), pianifica fino a 10 tentativi aggiuntivi - 11 tentativi di consegna in totale se l'endpoint non riesce.
- Il backoff tra i tentativi è esponenziale in minuti: dopo ogni errore, il tentativo successivo è idoneo dopo 1, 2, 4, 8, 16, 32, 64, 128, 256, quindi 512 minuti (ogni ritardo è il doppio del precedente). I nuovi tentativi vengono rilevati in base a una pianificazione all'incirca una volta al minuto, quindi la tempistica non è precisa al di sotto del secondo.
- Una consegna viene considerata riuscita quando l'endpoint restituisce 2xx entro 10 secondi.
- Una volta utilizzati tutti i tentativi, la consegna si interrompe; la riga in App → Registri mostra
failedoexhausteda seconda dello stato del canale.
Rispondere ai webhook
Il tuo endpoint dovrebbe restituire 200 OK il più rapidamente possibile. Elabora il payload in modo asincrono:
app.post('/webhook', (req, res) => {
res.status(200).send('OK') // Respond first
processChangeAsync(req.body) // Then process
})
Comportamento di nuovo tentativo
| Tentativo | Quando viene eseguito |
|---|---|
| 1 | Immediatamente quando viene rilevata la modifica |
| 2° | ≥ 1 minuto dopo il primo fallimento |
| 3° | ≥ 2 minuti dopo il 2° fallimento |
| 4° | ≥ 4 minuti dopo il 3° fallimento |
| 5° | ≥ 8 minuti dopo il 4° fallimento |
| 6° | ≥ 16 minuti dopo il 5° fallimento |
| 7° | ≥ 32 minuti dopo il 6° fallimento |
| 8 | ≥ 64 minuti (~1 h) dopo il 7° errore |
| 9° | ≥ 128 minuti (~2 h) dopo l'ottavo fallimento |
| 10 | ≥ 256 minuti (~4 h) dopo il 9° errore |
| 11 | ≥ 512 minuti (~8,5 h) dopo il decimo errore |
Dopo 11 tentativi non riusciti (1 iniziale + 10 tentativi), per quell'evento non viene eseguita alcuna ulteriore consegna automatica. Correggi il tuo endpoint e usa Avvia ora sul monitor se hai bisogno di un altro trigger.