Support client
API, webhooks ou BYOD : de quelle intégration avez-vous besoin ?
Trois façons de connecter initdesk à votre stack, et une seule d’entre elles est la nouvelle API, en ligne aujourd’hui sur developers.initdesk.com.
Si vous avez lu le marketing initdesk, vous avez probablement vu « connectez n’importe quelle API ». Cela veut en général dire Bring Your Own Data (BYOD) : initdesk appelle votre endpoint pour que les agents voient le palier d’abonnement, l’historique de commandes ou l’usage à côté d’un ticket.
Aujourd’hui nous lançons quelque chose de différent : l’API initdesk et la doc développeur sur developers.initdesk.com. Vos systèmes peuvent désormais appeler initdesk sur
https://api.initdesk.com pour lire et écrire tickets, demandeurs, conversations et contenu du Centre d’aide : la surface supportée pour CRM, outils internes, automatisation et portails custom.Trois chemins d’intégration. Trois directions de données. Choisissez selon qui initie la requête HTTP, pas selon le buzzword.
Trois directions (carte rapide)
| Intégration | Qui appelle qui | Idéal pour |
|---|---|---|
| API (nouvelle aujourd’hui) | Vous → initdesk (api.initdesk.com) | Créer ou lister des tickets, sync du Centre d’aide, CRM et outils internes |
| Webhooks | initdesk → votre URL HTTPS | Réactions temps réel quand messages, assignations ou statuts changent |
| BYOD | initdesk → votre endpoint client | Contexte client live dans la barre latérale du ticket et les brouillons IA |
Aucun ne remplace les autres. Beaucoup d’équipes utilisent BYOD plus l’API : contexte à côté du fil, tickets créés depuis le produit. Webhooks plus l’API est courant quand un événement doit déclencher un job qui récupère ensuite le détail complet du ticket.
Quand utiliser l’API
L’API est le défaut juste quand votre code a besoin de lire ou modifier des données initdesk à la demande.
Travaux typiques :
- Créer des tickets depuis un flux « Contacter le support » in-app, un CRM, ou un outil ops interne (vous choisissez la boîte ; le demandeur est un customer en termes API).
- Lister ou chercher des tickets pour des tableaux de bord, rapports SLA, ou digests d’escalade que vous possédez.
- Lire ou poster des messages quand vous construisez un portail custom ou mirrorez des fils ailleurs.
- Publier ou mettre à jour le Centre d’aide (articles et collections) depuis un dépôt, un CMS ou un pipeline de release.
Tout est scopé sous une organisation :
/organizations/{organization_id}/...
Utilisez l’ID d’organisation numérique depuis Paramètres → Général (pas le
public_id en chaîne des URL produit). Authentifiez-vous avec un jeton scopé à l’org sur chaque requête :X-Initdesk-Token: <your_token>
Émettez les jetons sous Paramètres → Accès API (Account Owner ou Admin). La valeur brute n’est montrée qu’une fois : stockez-la comme un mot de passe et révoquez-la en cas de fuite. Auth complète, limites de débit et relations d’entités vivent dans la doc développeur et le guide des entités.
Le schéma OpenAPI est sur api.initdesk.com/schema.yaml. Pour un premier appel minimal, voir Se connecter à l’API initdesk en 15 minutes, publié aujourd’hui avec ce billet.
Ce que l’API n’est pas : un remplacement des intégrations produit natives. La création/liaison d’incidents Linear tourne encore dans l’UI initdesk et la couche plugins ; il n’y a pas de ressource Linear dans l’API aujourd’hui. Le flux de Incidents Linear depuis les tickets de support s’applique encore : utilisez l’API pour les données ticket et message, pas pour ouvrir des incidents dans Linear.
Quand les webhooks suffisent
Choisissez les webhooks quand initdesk doit vous pousser un événement et que votre job est de réagir : notifier Slack, lancer n8n, invalider un cache, ou ajouter une ligne à une table analytics.
Configurez-les dans Paramètres → Webhooks. Choisissez les événements qui comptent (par exemple message créé, assigné, résolu, statut changé). Votre endpoint doit renvoyer une réponse 2xx en environ cinq secondes, sinon la livraison peut être marquée en échec.
Les webhooks portent des notifications, pas un export complet de votre compte. Si vous avez besoin de corps de tickets structurés, responsables ou champs du Centre d’aide à la demande, utilisez l’API (ou combinez : le webhook réveille votre worker, l’API fournit la charge utile).
Référence produit : Webhooks dans le Centre d’aide initdesk.
Quand BYOD est le bon choix
BYOD sert au contexte client au moment de répondre : statut de facturation, plan d’abonnement, dernière commande, feature flags, tout ce qui vit dans votre API d’admin.
initdesk fait un POST vers votre endpoint HTTPS (avec en-têtes d’auth optionnels que vous configurez) et rend la réponse dans la barre latérale du ticket via des templates Liquid. Ces mêmes données peuvent informer les brouillons IA, pour que les agents ne devinent pas depuis les seuls sujets.
BYOD ne crée pas de tickets, ne liste pas votre boîte, et ne publie pas d’articles d’aide. Il ne remplace pas l’API, et l’API ne tire pas de données arbitraires de vos systèmes dans la barre latérale. Pour ce découpage, voir Bring Your Own Data sur les mises à jour initdesk et le guide du plugin BYOD.
Combinaisons courantes (et un anti-pattern)
BYOD + création de ticket via API : un client ouvre le support depuis votre app ; vous
POSTez un ticket avec son e-mail et son sujet. Quand un agent ouvre le fil, BYOD a déjà chargé le contexte compte à côté.Webhook + récupération API : un webhook « message créé » déclenche votre worker ; le worker appelle retrieve ticket et list messages pour le fil complet avant de poster dans un canal interne.
API Centre d’aide + habitudes éditoriales : vous synchronisez les articles depuis git ; les agents suivent encore les schémas de contenu de Un libre-service qu’on utilise vraiment pour que recherche et chat IA restent dignes de confiance.
Anti-pattern : reconstruire initdesk dans votre base : poller l’API dans une boîte fantôme duplique l’état des responsables, les notes internes et la gestion du spam que vous avez déjà payés dans le produit. Préférez les webhooks ou des lectures ciblées pour les vues dont vous avez vraiment besoin.
Où aller ensuite
- Doc développeur (en ligne aujourd’hui) : developers.initdesk.com
- Premier appel API : Se connecter à l’API initdesk en 15 minutes
- Questions d’accès ou bêta : support@initdesk.com
initdesk est un help desk IA pour les petites équipes : boîte de réception partagée, Centre d’aide, BYOD, webhooks, et (depuis aujourd’hui) une API pour tickets, demandeurs, messages et contenu du Centre d’aide. Voir Mises à jour produit pour les notes de lancement et X @initdeskhq pour les annonces.