> For the complete documentation index, see [llms.txt](https://missiveapp.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://missiveapp.com/docs/developers/fr/webhooks.md). # Webhooks Configurez des webhooks pour recevoir des Notifications concernant les e-mails, les Libellés et d’autres événements Missive via HTTP POST. {% hint style="info" %} Missive propose une [intégration Zapier native](https://missiveapp.com/integrations/zapier) qui vous permet de déclencher des actions sur **de nouveaux contacts**, **de nouveaux commentaires**, **de nouveaux messages (e-mail, SMS)**, etc. {% endhint %} ## Webhooks Missive permet aux applications d’être informées de certaines actions (e-mails entrants, e-mails sortants, changements de libellé, etc.) sous la forme d’un HTTP `POST` payload envoyé à une URL. Exemple : créer une nouvelle entrée dans un CRM chaque fois qu’un e-mail est reçu et remplit certaines conditions. ## Configuration {% stepper %} {% step %} #### Créer une règle Webhook Accédez à **Paramètres** > **Règles**, créez une nouvelle règle et sélectionnez **Webhook** comme action. Lorsque vous enregistrez la règle, votre endpoint doit déjà être configuré pour recevoir une `POST` requête avec succès. Une requête de validation sera envoyée pour vérifier que votre endpoint fonctionne. {% endstep %} {% step %} #### Assurez-vous que votre endpoint traite correctement les requêtes * L’endpoint doit accepter les requêtes POST et répondre en moins de 15 secondes. * Si vous prévoyez d’exécuter un travail qui peut prendre plus de 15 secondes, utilisez une solution de tâche en arrière-plan (par exemple, consultez [cet article](https://devcenter.heroku.com/articles/background-jobs-queueing) sur les tâches en arrière-plan et la mise en file d’attente). {% endstep %} {% endstepper %} {% hint style="info" %} Remarque : vous devez être l’administrateur ou le propriétaire d’une organisation abonnée au [plan Productive](https://missiveapp.com/pricing) ou [Business plan](https://missiveapp.com/pricing) afin de créer des règles. {% endhint %} ## Format de la requête Chaque requête webhook contient un objet JSON. L’objet JSON suit cette structure générale : {% code title="webhook-payload.json" %} ```json { "rule": { "id": "45408b30-aa3a-45n1-bh67-0a0cb8da9080", "description": "Notify elfs", "type": "label_change" }, "conversation": { "id": "47a57b76-df42-4d8k-927x-80dbe5d87191", "subject": "Mordor GPS coordinates", "latest_message_subject": "Fwd: Mordor GPS coordinates", "Organisation": { "id": "93e5e5d5-11a2-4c9b-80b8-94f3c08068cf", "name": "Fellowship" }, "team": { "id": "2f618f9e-d3d4-4a01-b7d5-57124ab366b8", "name": "Hobbits", "organisation": "93e5e5d5-11a2-4c9b-80b8-94f3c08068cf" }, "color": null, "assignees": [ { "id": "6b52b6b9-9b51-46ad-a4e3-82ef3c45512c", "name": "Frodo Baggins", "email": "frodo@fellowship.org", "unassigned": false, "closed": false, "archived": false, "trashed": false, "junked": false, "assigned": true, "flagged": false, "snoozed": true } ], "assignee_names": "Frodo Baggins", "assignee_emails": "frodo@fellowship.org", "utilisateurs": [ { "id": "6b52b6b9-9b51-46ad-a4e3-82ef3c45512c", "name": "Frodo Baggins", "email": "frodo@fellowship.org", "unassigned": false, "closed": false, "archived": false, "trashed": false, "junked": false, "assigned": true, "flagged": false, "snoozed": true } ], "attachments_count": 0, "messages_count": 1, "authors": [ { "name": "Samwise Gamgee", "address": "sam@fellowship.org" } ], "drafts_count": 0, "send_later_messages_count": 0, "tasks_count": 0, "completed_tasks_count": 0, "shared_labels": [ { "id": "146ff5c4-d5la-3b63-b994-76711fn790lq", "name": "Elfs" } ], "shared_label_names": "Elfs", "app_url": "missive://mail.missiveapp.com/#inbox/conversations/47a57b76-df42-4d8k-927x-80dbe5d87191", "web_url": "https://mail.missiveapp.com/#inbox/conversations/47a57b76-df42-4d8k-927x-80dbe5d87191" }, "latest_message": { "id": "86ef8bb8-269c-4959-a4f0-213db4e67844", "subject": "Tr : Coordonnées GPS du Mordor", "preview": "Bonjour, M. Gamgee, j’ai découvert quelque chose de vraiment troublant à propos des coordonnées du Mordor que nous avions.", "type": "email", "delivered_at": 1548415828, "updated_at": 1548434556, "created_at": 1548434555, "email_message_id": "", "in_reply_to": [], "references": [], "from_field": { "name": "Samwise Gamgee", "address": "sam@fellowship.org" }, "to_fields": [ { "name": null, "address": "sam@fellowship.org" } ], "cc_fields": [], "bcc_fields": [], "reply_to_fields": [] } } ``` {% endcode %} ### Étapes de la règle Lorsque l’action webhook s’exécute dans un [étape de règle](https://missiveapp.com/docs/advanced-features/rules/steps), la `règle` l’objet comporte 3 autres clés : | Clé | Description | | ---------------------- | --------------------------------------------------------------------------------------------------------------------------- | | `parent_id` | ID de la règle ou de l’étape au-dessus de cette étape | | `delay_seconds` | Durée pendant laquelle l’étape attend après l’exécution de la règle ou de l’étape au-dessus d’elle, en secondes | | `delay_business_hours` | `null`, ou les Heures d’ouverture prises en compte pour ce délai : `{ "organization_id": "..." }` ou `{ "team_id": "..." }` | {% code title="webhook-payload.json" %} ```json { "rule": { "id": "8c1e2f4a-3b5d-4e6f-9a7b-1c2d3e4f5a6b", "description": "Transférer à l’équipe", "type": "incoming_email", "parent_id": "45408b30-aa3a-45n1-bh67-0a0cb8da9080", "delay_seconds": 10800, "delay_business_hours": { "organization_id": "93e5e5d5-11a2-4c9b-80b8-94f3c08068cf" } }, ... } ``` {% endcode %} Le `type` Le type d’une étape correspond au type de sa règle. Les règles qui ne sont pas des étapes n’ont pas ces clés. {% hint style="warning" %} **Modification incompatible pour WhatsApp** Pour les messages WhatsApp, le `identifiant` dans `from_field` et `to_fields` identifie les auteurs et les destinataires par leur **ID utilisateur limité à l’entreprise (BSUID)** : l’identifiant que Meta utilise pour faire référence à un utilisateur WhatsApp dans votre entreprise, au lieu du numéro de téléphone du contact. Par exemple, le `identifiant` passe de `whatsapp:+14155551234` à `whatsapp:US.13491208655302741918`. Si votre intégration s’appuyait sur ces `identifiant` si les valeurs sont un Numéro de téléphone pour WhatsApp, mettez-les à jour pour utiliser le BSUID. Le `nom d’utilisateur` le champ contient le nom d’utilisateur WhatsApp du contact lorsqu’il en a défini un, sinon il revient à son Numéro de téléphone. {% endhint %} ## Gestion des erreurs et nouvelle tentative Si la requête webhook renvoie un code d’état d’erreur ou ne renvoie pas de réponse dans les 15 secondes, la requête sera relancée jusqu’à 5 fois sur une période de 8 minutes. Si une règle webhook échoue plus de 50 fois d’affilée, la règle sera automatiquement désactivée. Vous pouvez la réactiver depuis l’onglet Paramètres des règles. Pour effectuer un travail qui peut prendre plus de 15 secondes, utilisez une solution de tâche en arrière-plan. Voir [cet article](https://devcenter.heroku.com/articles/background-jobs-queueing). ## Validation de la requête Si un secret de validation est défini sur l’action de votre règle, tous les headers de la requête webhook incluront un `X-Hook-Signature` signature de hachage du payload. Avec cette signature, vous pouvez valider que la requête vient de Missive. Pour ce faire, calculez vous-même la signature et comparez-la à celle fournie dans le header de la requête. La signature commence par `sha256=` suivi d’un haché hexadécimal HMAC. Exemple en Ruby : {% code title="request-signature-example.rb" %} ```ruby # # `secret` est le « Signature secret » que vous avez défini dans l’action de règle Missive # `request_body` est le corps complet de la requête HTTP # computed_signature = 'sha256=' + OpenSSL::HMAC.hexdigest( OpenSSL::Digest.new('sha256'), secret, request_body ) ``` {% endcode %} Assurez-vous de comparer la signature du header et celle que vous avez calculée à l’aide d’une méthode qui empêche les attaques temporelles contre les opérateurs d’égalité classiques. En Ruby, vous pouvez utiliser secure\_compare : {% code title="secure-compare-example.rb" %} ```ruby valid = Rack::Utils.secure_compare(x_hook_signature, computed_signature) ``` {% endcode %} ## FAQ sur les webhooks ### Comment puis-je confirmer qu’une règle a bien déclenché son webhook ? Activer **Afficher les événements de webhook des règles**. Accédez à **Paramètres** > **Préférences** > **Apparence** et, sous **Vue de conversation**, basculez **Afficher les événements de webhook des règles**. Astuce : saisissez `web` dans la barre de recherche des paramètres pour y accéder directement. Une fois activé, chaque fois qu’une règle déclenche une action webhook sur une conversation, Missive affiche une entrée directement dans la chronologie de la conversation. C’est une aide au débogage : si votre webhook ne se comporte pas comme prévu, l’entrée confirme si Missive a déclenché le webhook, ce qui vous permet de distinguer un problème côté règle d’un problème sur votre endpoint. Le paramètre est une préférence par utilisateur, désactivée par défaut. Il ne contrôle que la visibilité, donc l’activer ou le désactiver est entièrement rétrocompatible : cela ne crée ni ne supprime quoi que ce soit, et vous pouvez le basculer à tout moment. ### Mon webhook de règle ne fonctionne pas. La règle n’a-t-elle pas été déclenchée ? En général, non. Lorsqu’une action webhook ne produit pas le résultat attendu, la règle s’est presque toujours bien déclenchée et Missive a bien envoyé la `POST` requête. Le problème se situe généralement du côté de la réception : un endpoint mal configuré, un serveur qui ne répond pas, ou une réponse qui expire. Missive frappe à la bonne porte, mais personne ne répond. Activez **Afficher les événements de webhook des règles** (voir ci-dessus) pour confirmer que le webhook a été déclenché du côté de Missive, puis vérifiez les journaux de votre endpoint et le [Gestion des erreurs et nouvelle tentative](#error-handling-and-retry) comportement ci-dessus. ## Besoin de réponses plus précises ? [Contactez-nous](/docs/developers/fr/contact.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://missiveapp.com/docs/developers/fr/webhooks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.