I webhook WordPress trasformano il tuo sito da un sistema passivo a un’architettura event-driven, dove ogni azione — nuovo ordine, commento, registrazione utente, aggiornamento plugin — può innescare automaticamente processi esterni. Per le agenzie che gestiscono 10-50 siti, la wordpress webhook automazione elimina ore di lavoro manuale e riduce il ritardo tra evento e azione da minuti a millisecondi.
In questa guida vediamo come implementare webhook nativi e custom in WordPress, con esempi di codice reale che usiamo in AgencyPilot per automatizzare la gestione di decine di siti WordPress.
TL;DR
- I webhook sono callback HTTP inviati da WordPress a un endpoint esterno quando si verifica un evento specifico
- WordPress non ha webhook nativi per tutti gli eventi, ma è possibile crearli via codice con
wp_remote_post()e hook azionali - La combinazione webhook + REST API è la base dell’automazione moderna per agenzie
- La sicurezza è critica: ogni webhook deve verificare firma e origine
- Webhook e WP-Cron risolvono problemi diversi: i webhook sono push real-time, WP-Cron è polling schedulato
Cosa Sono i Webhook WordPress e Quando Usarli
Un webhook è una richiesta HTTP POST che WordPress invia a un URL esterno quando si verifica un evento specifico. A differenza di WordPress REST API, dove è il client a richiedere dati a WordPress, con i webhook è WordPress a spingere dati verso sistemi esterni.
Nella nostra esperienza di gestione di 50+ siti per clienti, i webhook diventano essenziali quando:
- Devi notificare un sistema esterno in tempo reale — un CRM, un tool di invoicing, una dashboard di monitoraggio
- Vuoi evitare il polling — invece di controllare ogni 5 minuti se ci sono nuovi lead, il sistema esterno riceve la notifica al momento esatto dell’evento
- Devi sincronizzare dati tra WordPress e servizi di terze parti — Stripe, Mailchimp, Slack, n8n, Zapier
- Costruisci un’architettura event-driven dove ogni azione su WordPress innesca una catena di processi automatizzati
Webhook nativi vs custom: il stato attuale
WordPress non include un sistema webhook nativo completo come Shopify o Stripe. Tuttavia, alcuni plugin e funzionalità core offrono webhook limitati:
| Sistema | Webhook nativi | Eventi supportati |
|---|---|---|
| WooCommerce | Sì (integrati) | Ordine creata, pagata, completata; prodotto aggiornato; rimborsi |
| WordPress Core | No | Richiede implementazione custom via hook + wp_remote_post() |
| Jetpack | Limitati | Pubblicazione post, nuovi commenti (via WP.com API) |
| Gravity Forms | Sì (add-on) | Invio form, post-creazione entry |
| Custom (codice) | Sì (su misura) | Qualsiasi evento WordPress: pubblicazione, login, aggiornamento plugin, upload media |
Per le agenzie che gestiscono siti eterogenei, l’approccio più scalabile è costruire webhook custom via codice. Meno dipendenze da plugin, più controllo su payload e sicurezza.
Come Creare Webhook Custom in WordPress: Esempio Completo
Ecco un esempio reale che usiamo in AgencyPilot: un webhook che notifica il nostro sistema di monitoring quando un nuovo utente si registra su un sito cliente.
1. Webhook per registrazione utente
add_action('user_register', 'agp_send_user_register_webhook', 10, 2);
function agp_send_user_register_webhook(\$user_id, \$userdata) {
\$webhook_url = get_option('agp_webhook_user_register_url');
if (empty(\$webhook_url)) {
return;
}
\$user = get_userdata(\$user_id);
\$payload = [
'event' => 'user.registered',
'site_url' => home_url(),
'site_name' => get_bloginfo('name'),
'user_id' => \$user_id,
'user_email' => \$user->user_email,
'user_login' => \$user->user_login,
'roles' => \$user->roles,
'registered' => \$user->user_registered,
'timestamp' => current_time('mysql'),
];
// Firma HMAC per sicurezza
\$secret = get_option('agp_webhook_secret');
\$signature = hash_hmac('sha256', wp_json_encode(\$payload), \$secret);
wp_remote_post(\$webhook_url, [
'body' => wp_json_encode(\$payload),
'headers' => [
'Content-Type' => 'application/json',
'X-Webhook-Signature' => \$signature,
'X-Webhook-Source' => home_url(),
'X-Webhook-Event' => 'user.registered',
],
'timeout' => 10,
'blocking' => false,
]);
}
Il parametro 'blocking' => false è fondamentale: fa sì che WordPress non attenda la risposta del webhook, evitando ritardi nell’esperienza utente. La registrazione dell’utente prosegue immediatamente.
2. Webhook per pubblicazione articoli
add_action('transition_post_status', 'agp_send_post_published_webhook', 10, 3);
function agp_send_post_published_webhook(\$new_status, \$old_status, \$post) {
if (\$new_status !== 'publish' || \$old_status === 'publish') {
return;
}
if (!in_array(\$post->post_type, ['post', 'product', 'page'])) {
return;
}
\$webhook_url = get_option('agp_webhook_post_publish_url');
if (empty(\$webhook_url)) return;
\$payload = [
'event' => 'post.published',
'site_url' => home_url(),
'post_id' => \$post->ID,
'post_title' => \$post->post_title,
'post_type' => \$post->post_type,
'permalink' => get_permalink(\$post->ID),
'author' => get_the_author_meta('display_name', \$post->post_author),
'timestamp' => current_time('mysql'),
];
\$secret = get_option('agp_webhook_secret');
\$signature = hash_hmac('sha256', wp_json_encode(\$payload), \$secret);
wp_remote_post(\$webhook_url, [
'body' => wp_json_encode(\$payload),
'headers' => [
'Content-Type' => 'application/json',
'X-Webhook-Signature' => \$signature,
'X-Webhook-Event' => 'post.published',
],
'timeout' => 10,
'blocking' => false,
]);
}
3. Webhook per aggiornamenti plugin
Questo è particolarmente utile per le agenzie: ricevere una notifica quando un plugin viene aggiornato su un sito cliente, per monitorare potenziali breaking changes.
add_action('upgrader_process_complete', 'agp_send_plugin_update_webhook', 10, 2);
function agp_send_plugin_update_webhook(\$upgrader, \$hook_extra) {
if (\$hook_extra['action'] !== 'update' || \$hook_extra['type'] !== 'plugin') {
return;
}
\$webhook_url = get_option('agp_webhook_plugin_update_url');
if (empty(\$webhook_url)) return;
\$updated_plugins = \$hook_extra['plugins'] ?? [];
foreach (\$updated_plugins as \$plugin_file) {
\$plugin_data = get_plugin_data(WP_PLUGIN_DIR . '/' . \$plugin_file);
\$payload = [
'event' => 'plugin.updated',
'site_url' => home_url(),
'plugin_file' => \$plugin_file,
'plugin_name' => \$plugin_data['Name'],
'new_version' => \$plugin_data['Version'],
'timestamp' => current_time('mysql'),
];
\$secret = get_option('agp_webhook_secret');
\$signature = hash_hmac('sha256', wp_json_encode(\$payload), \$secret);
wp_remote_post(\$webhook_url, [
'body' => wp_json_encode(\$payload),
'headers' => [
'Content-Type' => 'application/json',
'X-Webhook-Signature' => \$signature,
'X-Webhook-Event' => 'plugin.updated',
],
'timeout' => 10,
'blocking' => false,
]);
}
}
Webhook e REST API: La Combinazione Vincente per l’Automazione
I webhook diventano potenti quando combinati con la REST API di WordPress. L’architettura tipica per un’agenzia è:
- Webhook outbound (WordPress andrarr; sistema esterno): WordPress notifica eventi a n8n, Zapier o un endpoint custom
- Sistema esterno processa: n8n esegue logica (invia email, aggiorna CRM, genera report)
- REST API inbound (sistema esterno andrarr; WordPress): Il sistema esterno richiama WordPress via REST API per aggiornare dati
Questo pattern event-driven è quello che usiamo in AgencyPilot: ogni sito cliente invia webhook al nostro sistema centrale, che processa e — se necessario — interviene via REST API. Tutto automatizzato, tutto in tempo reale.
5 Esempi Reali di Automazione con Webhook per Agenzie
1. Notifica Slack per nuovi lead
Quando un utente compila un form di contatto su un sito cliente, un webhook invia i dati a un workflow n8n che posta un messaggio formattato nel canale Slack dell’agenzia. Tempo reale, zero ritardo.
2. Sincronizzazione contatti con CRM
Ogni nuova registrazione utente su WordPress triggera un webhook che invia i dati al CRM dell’agenzia (HubSpot, Pipedrive, o un sistema custom). Niente import manuale, niente doppia registrazione.
3. Auto-backup pre-aggiornamento
Quando un plugin viene aggiornato, il webhook notifica il sistema di backup che esegue uno snapshot del database. Se l’aggiornamento rompe qualcosa, il backup è già pronto. Questo è particolarmente utile per le agenzie che gestiscono molti siti.
4. Alert di sicurezza per login sospetti
Un webhook su wp_login con controllo IP geografico può inviare alert al sistema di monitoring quando un login proviene da un paese insolito o fuori orario lavorativo.
5. Report automatici per clienti
Ogni settimana, un webhook schedulato invia i dati di performance del sito (visitatori, pageviews, Core Web Vitals) al sistema di reporting che genera un PDF e lo invia al cliente. Tutto automatico.
Sicurezza dei Webhook: Firma, Verifica e Best Practice
I webhook espongono il tuo sito a rischi se non implementati correttamente. Ecco le best practice che seguiamo in AgencyPilot, in linea con la nostra guida alla sicurezza WordPress:
1. Firma HMAC obbligatoria
Ogni webhook deve includere una firma HMAC nell’header. L’endpoint ricevente verifica la firma prima di processare il payload:
// Lato ricevente (endpoint esterno)
\$signature = \$_SERVER['HTTP_X_WEBHOOK_SIGNATURE'] ?? '';
\$payload = file_get_contents('php://input');
\$expected = hash_hmac('sha256', \$payload, \$shared_secret);
if (!hash_equals(\$expected, \$signature)) {
http_response_code(401);
exit('Invalid signature');
}
2. Timeout breve e non bloccante
Usa sempre 'blocking' => false per i webhook outbound. Se l’endpoint è lento o down, WordPress non deve bloccarsi. Imposta un timeout di 10 secondi massimo.
3. Retry con backoff esponenziale
Se il webhook fallisce, implementa un sistema di retry. WordPress non lo fa nativamente, ma puoi schedulare un retry con WP-Cron:
\$response = wp_remote_post(\$webhook_url, \$args);
if (is_wp_error(\$response) || wp_remote_retrieve_response_code(\$response) >= 500) {
wp_schedule_single_event(time() + 300, 'agp_retry_webhook', [\$payload, \$webhook_url]);
}
4. Validazione del payload
L’endpoint ricevente deve validare ogni campo del payload. Non fidarti mai dell’input, anche se proviene dal tuo WordPress.
5. Rotazione del secret
Cambia il secret dei webhook periodicamente, come faresti con le password. Implementa un meccanismo di rotazione che non interrompa i webhook in flight.
Webhook vs WP-Cron: Quando Usare l’Uno o l’Altro
Webhook e WP-Cron risolvono problemi diversi. Capire la differenza è fondamentale per l’architettura della tua automazione:
| Caratteristica | Webhook | WP-Cron |
|---|---|---|
| Modalità | Push real-time (event-driven) | Polling schedulato (time-driven) |
| Latenza | Millisecondi | Minuti (dipende dai visitatori) |
| Direzione | WordPress andrarr; esterno | WordPress interno andrarr; task |
| Affidabilità | Dipende dall’endpoint | Dipende dal traffico del sito |
| Caso d’uso ideale | Notifiche real-time a sistemi esterni | Task schedulati interni (cleanup, sync) |
| Complessità | Media (richiede endpoint esterno) | Bassa (tutto interno a WordPress) |
In pratica, li usiamo insieme: i webhook per notifiche real-time e i task WP-Cron per retry, cleanup e operazioni schedulate. Non è una scelta binaria.
FAQ — Domande Frequenti sui Webhook WordPress
WordPress ha webhook nativi?
No, WordPress core non ha un sistema webhook nativo. WooCommerce e alcuni plugin offrono webhook integrati, ma per eventi custom devi implementarli via codice usando wp_remote_post() e gli hook azionali di WordPress.
Qual è la differenza tra webhook e REST API?
La REST API è un’interfaccia dove il client richiede dati a WordPress. I webhook sono il contrario: WordPress invia dati al client quando si verifica un evento. Complementari, non alternativi.
I webhook rallentano WordPress?
No, se implementati con 'blocking' => false. WordPress invia la richiesta HTTP in background e continua l’esecuzione senza attendere la risposta. È importante usare timeout brevi (10 secondi max).
Come testare i webhook in locale?
Usa servizi come webhook.site o RequestBin per ricevere e ispezionare i payload in fase di sviluppo. In produzione, implementa logging strutturato per diagnosticare problemi.
I webhook funzionano dietro CDN e firewall?
Sì, i webhook outbound (WordPress verso esterno) non sono affetti da CDN o firewall. I webhook inbound (esterno verso WordPress) richiedono che l’endpoint sia raggiungibile, ma possono essere protetti con WAF e verifiche di firma.