Crochets Web
Les crochets Web sont une extension d'une API, mais au lieu que votre code demande des données à notre plateforme API, Vonage vous envoie les données. Les données arrivent dans une requête Web à votre application. Un webhook peut être le résultat d'un appel API antérieur (ce type de webhook est également appelé " callback "), comme une demande asynchrone à l'API Number Insight. Les webhooks sont également utilisés pour notifier votre application d'événements tels qu'un appel ou un message entrant.
Étant donné que les serveurs Vonage doivent pouvoir envoyer des données à votre application via les webhooks, vous devez configurer un serveur web pour recevoir les requêtes HTTP entrantes. Vous devez également spécifier l'URL de chaque webhook sur votre serveur web afin que les données puissent être envoyées à chacun d'entre eux.
Flux de travail des webhooks
Avec les webhooks, il est important que l'URL à laquelle envoyer les webhooks soit configurée. Lorsque des données sont disponibles, Vonage envoie le webhook à votre application sous la forme d'une requête HTTP. Votre application doit répondre par un code de réussite HTTP pour indiquer qu'elle a reçu les données avec succès.
Le processus se déroule comme suit :
Les Webhooks constituent un mécanisme pratique permettant à Vonage d'envoyer des informations à votre application pour des événements tels qu'un appel ou un message entrant, ou un changement d'état de l'appel. Ils peuvent également être utilisés pour envoyer des informations de suivi telles qu'un reçu de livraison qui peut être disponible quelque temps après la demande à laquelle il se rapporte.
Quelles sont les API qui prennent en charge les webhooks ?
Les informations résultant des demandes adressées aux API Vonage prises en charge sont envoyées dans une demande HTTP à votre point de terminaison webhook sur un serveur HTTP. Pour configurer votre point de terminaison webhook, veuillez visiter le site Web de Vonage. Tableau de bord Vonage.
Vonage envoie et récupère les informations suivantes à l'aide de webhooks :
| Nom de l'API | Utilisation des webhooks |
|---|---|
| SMS API | Envoie l'état de livraison de votre message et reçoit les SMS entrants. |
| Voice API | Récupère le Appeler des objets de contrôle que vous utilisez pour contrôler l'appel à partir d'un point d'extrémité webhook, et envoie des informations sur l'état de l'appel à un autre point d'extrémité. Visualiser l'état de l'appel Référence pour les webhooks pour plus de détails. |
| Number Insight API Async avancée | Reçoit des informations complètes sur un numéro de téléphone. |
| Client SDK / Conversation API | Les événements de communication en temps réel (RTC) sont envoyés au webhook d'événements RTC. |
| Messages et Dispatch API | Prend en charge les webhooks relatifs aux messages entrants et à l'état des messages. |
| Verify API | Recevoir des mises à jour sur vos demandes de vérification. |
Définition des points de terminaison des webhooks
Les webhooks sont utilisés pour délivrer des messages entrants et des accusés de réception.
Messages entrants
Pour configurer le webhook utilisé pour les messages entrants, allez dans la section Vos Numbers du tableau de bord de Vonage. Cliquez sur 'edit' pour le numéro virtuel et définissez le paramètre URL de rappel.
Vous pouvez également utiliser la fonction CLI Vonage pour définir le point de terminaison des messages entrants pour un numéro individuel.
Récépissés de livraison
Voir le Récépissés de livraison dans la documentation du SMS.
L'API avancée de Number Insight vous permet d'envoyer les résultats d'une recherche de numéro de manière synchrone ou asynchrone.
Régler le callback à l'URL d'un webhook pour recevoir la consultation de manière asynchrone.
Voir Nombre Insight Advanced Async pour plus de détails.
Pour les requêtes de l'API Voice, les webhooks peuvent être définis au niveau de l'application, lors de la création d'un appel, ou dans les actions d'un NCCO.
Crochets web au niveau de l'application
Les numéros Vonage qui sont liés aux applications Vonage utiliseront le numéro answer_url pour récupérer un NCCO, et le event_url pour vous envoyer des informations sur l'état de l'appel. Les fallback_answer_url peut être configuré en option. Cette option est utilisée lorsque answer_url est hors ligne ou renvoie un code d'erreur HTTP. Il est également utilisé lorsqu'un événement est censé délivrer un NCCO le jour de l'événement. event_urlmais event_url est hors ligne ou renvoie un code d'état HTTP.
Vous pouvez les définir à l'aide de la fonction Application API, dans le tableau de bord ou en utilisant le CLI Vonage l'outil.
Crochets web au niveau des numéros
Vous pouvez définir un webhook d'état pour chaque numéro que vous achetez. Celui-ci sera utilisé pour vous envoyer des événements concernant chaque numéro.
Ceux-ci peuvent être configurés dans la section Numbers de la base de données des Tableau de bordpar l'intermédiaire du CLI Vonage ou par l'intermédiaire du Mise à jour d'un nombre (plus précisément, l'appel à l'API voiceStatusCallback ).
Lors de la création d'un appel sortant
Quand passer un nouvel appel sortantvous devez définir le answer_url dans l'appel vers une URL contenant un NCCO. Les serveurs de Vonage récupèrent le NCCO à partir de ce point de terminaison et suivent ses instructions pour traiter l'appel sortant.
Réponse URL payload
La charge utile pour le answer_url est :
| Paramètres | Description |
|---|---|
to | Le numéro appelé |
from | Le numéro de l'appelant |
conversation_uuid | L'UUID du conversation |
uuid | L'UUID du jambe |
Exemple d'URL :
/webhooks/answer?to=447700900000&from=447700900001&conversation_uuid=CON-aaaaaaaa-bbbb-cccc-dddd-0123456789ab&uuid=aaaaaaaa-bbbb-cccc-dddd-0123456789cd
L'intérieur d'un OCNI
À l'intérieur d'un NCCO, les types d'action suivants prennent une URL de webhook à utiliser lors de l'exécution de cette action :
- record.eventUrl - définir le point de terminaison du webhook qui reçoit des informations sur l'enregistrement d'un appel ou d'une conversation
- conversation.eventUrl - définir l'URL du point de terminaison du webhook que Vonage appelle de manière asynchrone lorsqu'une conversation change d'état pour cette action de conversation
- connect.eventUrl - définir l'URL du point de terminaison du webhook que Vonage appelle de manière asynchrone lorsqu'une conversation change d'état pour cette action de connexion
- input.eventUrl - définir l'URL du point de terminaison du webhook Vonage envoie les chiffres pressés par l'appelant
- stream.streamUrl - définir un tableau d'URL pointant vers les points de terminaison du webhook hébergeant le fichier audio à transmettre à l'appel ou à la conversation
Délais d'attente pour les webhooks
Si la réponse, l'événement ou l'URL de repli est inaccessible pendant un certain temps, ou si le temps de réponse dépasse une certaine limite, Vonage réessayera la demande une fois. Les délais de connexion et de lecture par défaut de la plateforme sont les suivants :
| Type de webhook | Délai de connexion | Délai d'attente de la socket |
|---|---|---|
| Réponse | 1 seconde | 5 secondes |
| Événement | 1 seconde | 10 secondes |
| Repli | 1 seconde | 5 secondes |
Ces valeurs par défaut peuvent être modifiées par l'intermédiaire d'un paramètre Application API ou dans l'appel Tableau de bord en sélectionnant l'application, puis en cliquant sur le bouton Editer et faire défiler jusqu'à la section Capacités / Voix :

De plus amples informations sur ces délais d'attente sont disponibles dans la rubrique Délais d'attente pour le webhook de l'API Applications vue d'ensemble documentation.
Un Applications peut recevoir des événements RTC par l'intermédiaire du Crochet web RTC.
Vous définissez l'URL du webhook de l'événement RTC lorsque vous créer l'application en utilisant la langue de votre choix.
De plus amples informations sur la création d'une application dotée de fonctionnalités RTC sont également disponibles dans la rubrique Documentation sur l'API des applications.
Verify envoie des rappels d'événement et de résumé pour les mises à jour de vos demandes de vérification. Si vous choisissez l'authentification silencieuse ou WhatsApp Codeless comme l'un de vos canaux d'authentification, vous devrez recevoir des rappels pour que la demande aboutisse.
L'URL vers laquelle les rappels seront envoyés peut être configurée dans votre paramètres de l'application sur le tableau de bord du développeur. Voir la page Référence API par exemple pour les rappels.
Deux webhooks sont pris en charge par les API Messages et Dispatch : le webhook sur l'état des messages et le webhook sur les messages entrants. L'état du message est reçu sur le webhook de l'état du message et le message lui-même est reçu sur le webhook du message entrant. La configuration de ces webhooks est décrite en détail dans la rubrique Configuration des webhooks pour les API Messages et Dispatch.
Réception de webhooks
Pour interagir avec les webhooks de Vonage :
- Créez un Account Vonage.
- Rédigez des scripts pour traiter les informations envoyées ou demandées par Vonage. Votre serveur doit répondre avec un code d'état de succès (tout code d'état entre 200 OK et 205 Reset Content) aux messages entrants de Vonage. Tout autre code que
2xxfera en sorte que les serveurs de Vonage tentent à nouveau de livrer le rappel. - Publiez vos scripts en les déployant sur un serveur (pour un développement local, essayez Ngrok).
- Configurer un point de terminaison webhook dans l'API que vous souhaitez utiliser.
- Effectuez une action (comme l'envoi d'un SMS) qui déclenchera ce webhook.
Les informations relatives à votre demande sont ensuite envoyées à votre point de terminaison webhook.
Décodage des webhooks signés
La signature des webhooks est activée par par défaut pour les API Messages, Dispatch, Verify et Voice. Elles permettent à votre application de vérifier qu'une demande provient bien de Vonage et que son contenu n'a pas été altéré pendant le transport. Lors de la réception d'une demande, le webhook entrant inclura un jeton JWT dans l'en-tête d'autorisation qui est signé avec votre secret de signature.
NOTE: Pour les applications vocales créées précédemment, Signed Webhooks est désactivé par défaut. Pour l'activer manuellement, allez dans les paramètres de l'application dans le tableau de bord, cliquez sur le lien "Afficher les fonctionnalités avancées" dans la section Capacité vocale, puis activez l'option Utiliser des webhooks signés vérifier :

Vous pouvez également le désactiver pour les nouvelles applications en cochant cette case (non recommandé, à n'utiliser que dans des cas exceptionnels).
La validation des webhooks signés offre un certain nombre d'avantages en matière de sécurité, notamment :
- La possibilité de vérifier qu'une demande provient de Vonage
- S'assurer que le message n'a pas été altéré pendant son acheminement
- Défense contre l'interception et le rejeu ultérieur
Validation des webhooks signés
La validation des webhooks signés se fait en deux temps :
- Verify the request
- Verify the payload (optionnel)
Verify the request
Les webhooks incluront un JWT dans le fichier Authorization header. Utilisez la clé API incluse dans les revendications JWT pour identifier lequel de vos secrets de signature a été utilisé pour signer la demande. Le secret utilisé pour signer la demande correspond au secret de signature associé à l'en-tête api_key inclus dans les revendications JWT. Vous pouvez identifier votre secret de signature sur la page Tableau de bord. Il est recommandé que les secrets de signature ne soient pas inférieurs à 32 bits pour garantir leur sécurité.
NOTE: Le signature method n'affecte pas la méthode utilisée pour signer les webhooks de l'API Messages, SHA-256 est toujours utilisé.
Verify que la charge utile n'a pas été altérée en cours de route
Une fois que vous avez vérifié l'authenticité de la demande, vous pouvez éventuellement vérifier que la charge utile de la demande n'a pas été altérée en comparant un hachage SHA-256 de la charge utile à la balise payload_hash trouvé dans les revendications JWT. S'ils ne correspondent pas, c'est que la charge utile a été altérée pendant le transit. La vérification de la charge utile n'est nécessaire que si vous utilisez HTTP plutôt que HTTPS, car la sécurité de la couche de transport (TLS) empêche la falsification de la charge utile. Attaques MITM.
NOTE : Dans le cas rare d'une erreur interne, il est possible que le service de rappel envoie un rappel non signé. En renvoyant une réponse HTTP 5xx, une nouvelle tentative sera déclenchée, ce qui donnera au système le temps de résoudre l'erreur et de signer les futurs rappels.
L'exemple de code ci-dessous montre comment vérifier la signature d'un webhook. Il est recommandé d'utiliser le protocole HTTPS, qui garantit que la demande et la réponse sont cryptées à la fois par le client et par le serveur.
| Clé | Description |
|---|---|
VONAGE_API_KEY | Your Vonage API key (see it on your dashboard). |
VONAGE_SIGNATURE_SECRET | The secret used to sign the request corresponds to the signature secret associated with the |
Conditions préalables
npm install @vonage/jwt expressRédiger le code
Ajouter ce qui suit à verify-signed-webhook.js:
const app = require('express')();
const bodyParser = require('body-parser');
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({
extended: true,
}));
app
.route('/webhooks/inbound-message')
.post(handleInboundMessage);
const handleInboundMessage = (request, response) => {
const token = request.headers.authorization.split(' ')[1];
if (verifySignature(token, VONAGE_API_SIGNATURE_SECRET)) {
console.log('Valid signature');
} else {
console.log('Invalid signature');
}
response.send(200);
};
app.listen(process.env.PORT || 3000);
Exécutez votre code
Enregistrez ce fichier sur votre machine et exécutez-le :
Conditions préalables
composer require vonage/clientCréez un fichier nommé verify-signed-webhooks.php et ajoutez le code suivant :
Exécutez votre code
Enregistrez ce fichier sur votre machine et exécutez-le :
Conditions préalables
pip install vonage python-dotenv fastapi[standard]Rédiger le code
Ajouter ce qui suit à verify-signed-webhooks.py:
import os
from os.path import dirname, join
from dotenv import load_dotenv
# Load the environment
envpath = join(dirname(__file__), '../.env')
load_dotenv(envpath)
VONAGE_SIGNATURE_SECRET = os.getenv('VONAGE_SIGNATURE_SECRET')
from fastapi import FastAPI, Request
from vonage_jwt.verify_jwt import verify_signature
app = FastAPI()
@app.get('/inbound')
async def verify_signed_webhook(request: Request):
# Need to get the JWT after "Bearer " in the authorization header
auth_header = request.headers["authorization"].split()
token = auth_header[1].strip()
if verify_signature(token, VONAGE_SIGNATURE_SECRET):
print('Valid signature')
else:
print('Invalid signature')Exécutez votre code
Enregistrez ce fichier sur votre machine et exécutez-le :
Exemple de JWT signé
// header
{
"alg": "HS256",
"typ": "JWT",
}
// payload
{
"iat": 1587494962,
"jti": "c5ba8f24-1a14-4c10-bfdf-3fbe8ce511b5",
"iss": "Vonage",
"payload_hash" : "d6c0e74b5857df20e3b7e51b30c0c2a40ec73a77879b6f074ddc7a2317dd031b",
"api_key": "a1b2c3d",
"application_id": "aaaaaaaa-bbbb-cccc-dddd-0123456789ab"
}
En-tête JWT signé
Le contenu de l'en-tête JWT signé est décrit dans le tableau suivant :
| En-tête | Valeur |
|---|---|
alg | HS256 |
typ | JWT |
Charge utile JWT signée
Le contenu de la charge utile du JWT signé est décrit dans le tableau suivant, en utilisant les valeurs incluses dans l'exemple de JWT signé présenté précédemment :
| Champ d'application | Exemple de valeur | Description |
|---|---|---|
iat | 1587494962 | Heure à laquelle le JWT a été émis. Horodatage Unix en SECONDES. |
jti | c5ba8f24-1a14-4c10-bfdf-3fbe8ce511b5 | Un identifiant unique pour le JWT. |
iss | Vonage | L'émetteur du JWT. Il s'agira toujours de "Vonage". |
payload_hash | d6c0e74b5857df20e3b7e51b30c0c2a40ec73a77879b6f074ddc7a2317dd031b | Un hachage SHA-256 de la charge utile de la demande. Peut être comparé à la charge utile de la demande pour s'assurer qu'elle n'a pas été altérée pendant le transit. |
api_key | a1b2c3d | La clé API associée au compte qui a effectué la demande initiale. |
application_id | aaaaaaaa-bbbb-cccc-dddd-0123456789ab | (Facultatif) L'identifiant de l'application qui a effectué la demande initiale, si une application a été utilisée. |
Tester les webhooks localement
Afin de tester le bon fonctionnement des webhooks sur votre application exécutée localement, vous devrez créer un tunnel sécurisé entre Vonage et votre application. Vous pouvez le faire à l'aide d'une application de tunnel sécurisé telle que Ngrok. Voir le Tester avec Ngrok pour plus d'informations.
Configuration du pare-feu
Si vous limitez le trafic entrant (y compris les accusés de réception), vous devez ajouter les adresses IP de Vonage à la liste des adresses IP approuvées de votre pare-feu. Vous trouverez plus d'informations à ce sujet dans notre base de connaissances :
- Gammes Voix IP
- Plages IP SMS
- Messages et plages IP d'envoi
- Nombre de plages IP Insight Advanced Async
Conseils pour déboguer les webhooks
Commencer modestement - Publiez le plus petit script possible auquel vous pouvez penser pour répondre à la réception du webhook et éventuellement imprimer des informations de débogage. Cela permet de s'assurer que l'URL est bien celle que l'on croit et que l'on peut voir la sortie ou les journaux de l'application.
Coder de manière défensive - Vérifiez que les valeurs de données existent et contiennent ce que vous attendez avant de les utiliser. En fonction de votre configuration, vous pourriez recevoir des données inattendues ; gardez donc toujours cela à l'esprit.
Voir des exemples - Vonage fournit des exemples mis en œuvre avec plusieurs piles technologiques dans le but d'aider le plus grand nombre de développeurs possible. Pour un exemple de code utilisant des webhooks, voir ce qui suit :
Vous pouvez également consulter la section des extraits de code de la documentation de l'API que vous utilisez.
Voir aussi
- De plus amples informations sur les types de webhooks et les capacités des applications sont disponibles dans la rubrique Documentation relative à l'application.