API Webhook v2
Panoramica
Riepilogo delle funzionalità
Piano | Prezzo | Numero di webhook |
---|---|---|
Self-Serve Pro | 5.000 $/mese | 1 |
Enterprise | Contatta il team vendite | 5+ |
Prodotti che supportano i webhook
Gestione dei webhook
1. Sviluppa una Webhook Consumer App
- Crea un’app web con un URL HTTPS pubblicamente accessibile che fungerà da endpoint del webhook per ricevere gli eventi.
- Il path della URI è totalmente a tua discrezione. Questo esempio è valido: https://mydomain.com/service/listen
- Se stai gestendo webhooks da varie fonti, uno schema comune è: https://mydomain.com/webhook/twitter
- Nota che l’URL specificato non può includere una porta (https://mydomain.com:5000/NoWorkie).
- Un primo passo è scrivere codice che riceva una richiesta GET di X Challenge Response Check (CRC) e risponda con un JSON correttamente formattato.
- Registra l’URL del tuo webhook. Invierai una richiesta POST all’endpoint /2/webhooks con l’URL nel body JSON. Quando effettui questa richiesta, X invierà una richiesta CRC alla tua app web.
- Quando un webhook viene registrato correttamente, la risposta includerà un webhook id. Questo webhook id sarà necessario in seguito quando effettuerai richieste ai prodotti che supportano i webhook.
- X invierà richieste POST contenenti eventi all’URL che hai registrato. Questi eventi saranno codificati in JSON. Vedi qui esempi di payload JSON del webhook.
Facoltativo: utilizzare xurl per i test
xurl
da GitHub, configura l’autorizzazione, quindi esegui:
- Durante la registrazione dell’URL del webhook, la tua web app deve utilizzare il consumer secret della tua App per la cifratura del controllo CRC.
- Tutti i Messaggi Diretti in arrivo saranno recapitati tramite webhook. Anche tutti i Messaggi Diretti inviati tramite POST /2/dm_conversations/with/:participant_id/messages saranno recapitati tramite webhook. In questo modo la tua web app può rilevare i Messaggi Diretti inviati tramite un client diverso.
- Se hai più di una web app che condivide lo stesso URL del webhook e lo stesso utente associato a ciascuna app, lo stesso evento verrà inviato al tuo webhook più volte (una per ogni web app).
- In alcuni casi, il tuo webhook può ricevere eventi duplicati. La tua app webhook dovrebbe gestire questa eventualità ed effettuare la deduplicazione in base all’id evento.
-
Vedi il codice di esempio:
- Account Activity API Setup, una web app Node che mostra gli eventi del webhook utilizzando il tier Enterprise dell’Account Activity API.
2. Protezione dei webhook
- I controlli challenge-response consentono a X di confermare l’effettiva titolarità della web app che riceve gli eventi webhook.
- L’intestazione di firma in ogni richiesta POST ti consente di verificare che X sia l’origine dei webhook in arrivo.
3. The Webhooks API
https
pubblicamente accessibile deve essere incluso nel corpo JSON.Iniziamo registrando un nuovo URL di webhook per il contesto applicativo indicato. Autenticazione: OAuth2 App only Bearer Token
- Bearer token
<BEARER_TOKEN>
ad es.AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
- URL
<URL>
p.es.https://yourdomain.com/webhooks/twitter/
Motivo | Descrizione |
---|---|
CrcValidationFailed | L’URL di callback non ha risposto correttamente al controllo CRC (ad esempio, timeout, risposta errata). |
UrlValidationFailed | L’URL di callback fornito non soddisfa i requisiti (ad esempio, non è https , formato non valido). |
DuplicateUrlFailed | Per l’URL di callback fornito risulta già registrato un webhook dalla tua applicazione. |
WebhookLimitExceeded | La tua applicazione ha raggiunto il numero massimo di configurazioni di webhook consentite. |
-
Bearer token
<BEARER_TOKEN>
ad es.AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
-
URL
<URL>
ad es.https://yourdomain.com/webhooks/twitter/
webhook_id
specifico. L’ID può essere ottenuto dalla risposta di creazione POST /2/webhooks
o dalla risposta di elenco GET /2/webhooks
.
Autenticazione:
OAuth2 App only Bearer Token
- Bearer Token
<BEARER_TOKEN>
ad es.AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
Parametro | Descrizione |
---|---|
webhook_id | L’id del webhook da eliminare. |
Motivo | Descrizione |
---|---|
WebhookIdInvalid | Il webhook_id fornito non è stato trovato o non è associato alla tua App. |
valid
.
Autenticazione:
OAuth2 App Only Bearer Token
- Bearer token
<BEARER_TOKEN>
es.AAAAAAAAAAAA0%2EUifi76ZC9Ub0wn...
Parametro | Descrizione |
---|---|
webhook_id | L’id del webhook da convalidare. |
valid
nella risposta riflette lo stato dopo il tentativo di verifica. Se il controllo CRC ha esito positivo, lo stato del webhook verrà aggiornato a valido. È possibile verificare lo stato corrente utilizzando GET /2/webhooks
.
Motivo | Descrizione |
---|---|
WebhookIdInvalid | Il webhook_id fornito non è stato trovato oppure non è associato alla tua App. |
CrcValidationFailed | L’URL di callback non ha risposto correttamente alla richiesta di verifica CRC. |
4. Il controllo CRC
- Durante la registrazione iniziale del webhook (
POST /2/webhooks
) - Ogni ora da parte di X per la verifica
- Manualmente tramite
PUT /2/webhooks/:id
- Usa crc_token come messaggio
- Usa il consumer secret dell’App come chiave
- Crea un hash HMAC SHA-256
- Codifica il risultato in Base64
App di esempio
- Simple webhook server
- Un singolo script Python che mostra come rispondere al controllo CRC e accettare eventi POST.
- Account Activity API sample dashboard
- Un’app web scritta con bun.sh che consente di gestire webhook, sottoscrizioni e ricevere eventi in tempo reale direttamente nell’App.