Invio di webhook in uscita
“Dovremmo offrire dei webhook.”
Sembra basti un solo endpoint. In realtà è tutto questo elenco — più quell'altra metà di cui nessuno si ricorda, finché un cliente non chiede perché un evento di martedì scorso non sia mai arrivato.
- Firma HMAC, con uno schema che i destinatari conoscono già
- Timestamp e ID di consegna all'interno della firma, altrimenti si rischiano replay attack
- Tentativi esponenziali che resistono anche se il destinatario resta offline per tutto il giorno
- Jitter, altrimenti ogni invio in coda travolgerà il destinatario non appena torna online
- Capire quali errori vale la pena riprovare e quali no
- Rotazione dei secret con periodo di sovrapposizione, perché nessuno può effettuare il cambio all'istante
- Un log append-only di ogni tentativo e risposta
- Un modo per permettere ai tuoi clienti di consultare quel log senza doverti scrivere via email
HookPulse include tutto questo, dietro una singola POST.
Nessuna carta richiesta. 2.000 consegne incluse nella prova.
Una sola richiesta in entrata. Di tutto il resto ci occupiamo noi.
Il tuo handler risponde immediatamente — un webhook non dovrebbe mai vincolare la tua richiesta alla lentezza del server di qualcun altro. Da lì in poi ce ne occupiamo noi: firmato, consegnato, ritentato e registrato.
Vedi lo snippet di verificaawait fetch('https://hookpulse.altixcode.com/api/v1/apps/APP_ID/events', {
method: 'POST',
headers: { Authorization: 'Bearer hp_…' },
body: JSON.stringify({
type: 'invoice.paid',
payload: { id: 'in_123', amount: 4900 },
dedupeKey: 'invoice-123-paid',
}),
})Perché non costruirlo da soli?
La maggior parte dei team ci prova. La firma e il primo retry richiedono una giornata di lavoro. Il resto — jitter, finestre di replay, sovrapposizione nella rotazione, un log visibile ai clienti — è la parte che viene tagliata, ed è proprio quella che i tuoi clienti notano.
L'elenco completo, non solo la prima metà
La firma e un singolo tentativo di retry vengono implementati in un pomeriggio da quasi tutti i team che ci provano. Jitter, logiche di rieseguibilità, rotazione con sovrapposizione e un log consultabile dai clienti sono la parte che viene sacrificata per rispettare le scadenze — e la parte che il cliente nota non appena manca.
L'URL del tuo endpoint viene riverificato prima di ogni tentativo, non solo al salvataggio
Un hostname che punta alla tua rete privata viene rifiutato al momento del salvataggio e rifiutato di nuovo, tramite indirizzo risolto, subito prima di ogni tentativo di consegna — e i redirect non vengono mai seguiti verso un host non specificato da te. Un sistema di invio webhook che effettua il controllo una sola volta permette a un endpoint mal configurato o malevolo di sondare la tua infrastruttura.
Un log consultabile dai tuoi clienti, non solo da te
Il log delle consegne è già disponibile come API delimitata, firmata e a tempo, pensata per essere integrata direttamente nella pagina impostazioni della tua app — così la domanda "perché il mio webhook non è arrivato?" smette di essere un ticket di supporto da gestire a mano.
La pianificazione dei retry, spiegata in modo chiaro e senza ambiguità.
Sei tentativi distribuiti su oltre sette ore, ciascuno con jitter per evitare che un destinatario appena ripartito venga sommerso di richieste tutte insieme. Poi ci fermiamo e ti avvisiamo — una consegna fallita per un'intera giornata richiede l'intervento di una persona, non l'ennesima richiesta automatica.
- immediatamente
- +15stentativo 2
- +2mtentativo 3
- +15mtentativo 4
- +1htentativo 5
- +6htentativo 6
Prezzo calcolato a consegna.
Un evento distribuito su cinque endpoint equivale a cinque consegne, perché sono cinque le richieste che abbiamo effettuato e cinque le serie di tentativi di cui siamo responsabili. I tentativi di una stessa consegna non vengono conteggiati di nuovo.
Scale
A marketplace, or an API with real traffic.
$149/ mese
1,000,000 deliveries / month
Inizia con Scale