Intégrateur Zendesk
Intégration de l'API Zendesk dans votre système
Nous branchons Zendesk à votre application métier : tickets, utilisateurs et organisations dans les deux sens, avec le contexte produit sur chaque dossier.
- Équipe produit senior
- connecteurs de support en production
- du cadrage au monitoring
Pourquoi faire appel à un intégrateur Zendesk et que peut-on connecter à Zendesk ?
Zendesk est l'une des plateformes de support client les plus utilisées par les entreprises en croissance pour centraliser les demandes de leurs clients. Un intégrateur Zendesk relie Zendesk à votre application, votre CRM ou votre entrepôt de données pour que les tickets soient créés automatiquement avec le contexte complet du compte, que les mises à jour dans Zendesk se reflètent dans votre logiciel, et que les données de support alimentent votre reporting. Le travail consiste à maintenir la cohérence des identifiants entre Zendesk et vos autres systèmes, et à éviter que les automations internes s'écrasent mutuellement.
Ce que débloque un intégrateur Zendesk
Incident applicatif, ticket nommé
Création depuis votre produit, external_id = id incident, organisation = compte client. L'agent et l'utilisateur parlent du même dossier.
Miroir de statut dans le portail
Requests API pour l'end-user, Tickets API pour l'agent interne. open, pending, solved : le client voit l'état sans ouvrir Zendesk.
Entrepôt d'analytics support
Incremental Tickets + Users, cursor, sans polluer le quota de l'agent. SLA, files, CSAT dans votre BI, pas dans un export CSV du vendredi.
Utilisateurs alignés avec le CRM
Les fiches Zendesk suivent le CRM sans créer de doublons. L'agent et le commercial parlent du même compte.
Ce que ça change dans votre support
La technique au service d'un résultat mesurable : un ticket sans collision, un contexte produit, une BI sans CSV.
Plus d'écrasement entre agents
Quand une règle Zendesk et votre connecteur touchent le même ticket, personne n'écrase l'autre. Le dossier reste cohérent.
La BI support sans export du vendredi
Les tickets et utilisateurs alimentent votre entrepôt au fil de l'eau. SLA, files et CSAT vivent dans votre BI.
Le portail client reste fluide
Les mises à jour sont regroupées. Vous évitez de saturer Zendesk pendant une escalade et de bloquer les agents.
Le plan Zendesk est cadré dès le devis
Le volume d'appels dépend de l'offre. On dimensionne le connecteur sur votre Suite réelle, pas sur une démo illimitée.
Comment nous livrons votre connecteur Zendesk
Cadrage
Quels flux, Tickets ou Requests, plan Suite réel, High Volume ou non, RGPD (user = personne). On liste les cas limites avant d'écrire une ligne de code.
Développement
HMAC TIMESTAMP + raw body, Incremental cursor, file par user à 5 / min, agrégation des updates ticket. Token bucket aligné sur le plan.
Recette
Collision automation vs connecteur, ticket SCRUBBED, doublons time-based, secret de test documenté. On rejoue le 429 sur update ticket.
Monitoring
X-Rate-Limit, Retry-After, jobs TooManyJobs, invocations webhook. Vous savez qu'un flux est cassé avant vos agents.
Ce que permet l'API Zendesk
- Tickets et Requests
- CRUD, create_many, merge, CCs, followers, custom fields, external_id. Statuts new, open, pending, hold, solved, closed. Types problem, incident, question, task.
- Users et organizations
- End-users, agents, admins. POST /api/v2/users/create_or_update à 5 / min / user. Incremental export users, même discipline que les tickets.
- Incremental Export
- Cursor recommandé pour tickets et users. Time-based : doublons attendus, pas de trou, dernière minute exclue. Tickets deleted restent exportés, puis SCRUBBED, puis tombent vers 120 jours.
- Webhooks signés
- CRUD, monitoring des invocations. X-Zendesk-Webhook-Signature = base64(HMACSHA256(TIMESTAMP + BODY)). Essai : 10 webhooks, 60 invocations / min.
Le vocabulaire de l'API Zendesk
- Tickets vs Requests
- Tickets : vue agent, commentaires privés inclus. Requests : vue end-user, commentaires publics seulement. Un connecteur qui mélange les deux fuit de la note interne.
- safe_update
- Update conditionnel avec updated_stamp. Sans lui, une automation et votre connecteur s'écrasent. C'est le détail qui sépare un PoC d'un connecteur multi-agents.
- Incremental Export
- Cursor-based recommandé. Time-based : filtrer id+updated_at (doublons), repartir de end_time (pas de trou), données de la dernière minute exclues. Ce n'est pas un list paginé.
- X-Zendesk-Webhook-Signature
- base64(HMACSHA256(TIMESTAMP + BODY)), plus X-Zendesk-Webhook-Signature-Timestamp. Secret de test public : dGhpc19zZWNyZXRfaXNfZm9yX3Rlc3Rpbmdfb25seQ==.
- external_id
- Lien entre le ticket Zendesk et l'objet métier (commande, chantier, numéro de série). Clé d'idempotence à la création.
- High Volume API
- Add-on qui porte le plafond à 2 500 / min (Growth+ / Support Professional+, 10 sièges min). Ce n'est pas un bonus empilable sur le quota Suite.
Les contraintes réelles de l'API Zendesk
30 updates / 10 minutes / ticket / agent
Plus 100 / min / compte (300 avec High Volume). Un workflow d'escalade naïf sature ce plafond. On agrège les patches. C'est le 429 le plus mal diagnostiqué.
List all tickets n'est pas l'outil de synchro
Au-delà de la page 500 : 50 / min. La doc Tickets renvoie vers Incremental Export. Un job quotidien sur GET /tickets?page= est un anti-pattern documenté.
create_or_update : 5 / min / user
Update User et create_or_update partagent ce seau. Une reprise CRM se file par utilisateur. Incremental users : 10 / min (30 avec High Volume).
tags remplace l'ensemble
Un PUT naïf efface les tags posés par les agents. On relit avant d'écrire, ou on n'envoie tags que lorsque c'est l'intention. description est en lecture ; comment écrit le premier message.
API Zendesk ou API Freshdesk ?
Deux helpdesks entreprise. Zendesk pèse sur l'export, safe_update et les webhooks ; Freshdesk sur un CRUD plus simple et des automations.
| Critère | ZendeskCette page | FreshdeskHelpdesk Freshworks |
|---|---|---|
| Tickets | new/open/pending/hold/solved/closed | Statuts numériques 2/3/4/5 |
| Synchro de stock | Incremental Export (cursor) | List paginé, include facturé |
| Webhooks | API + HMAC SHA-256 | Automations, pas de bus dédié v2 |
| Quota | 200 à 2 500 / min selon Suite | Lu dans X-RateLimit-Total |
| Identité | Users, create_or_update 5 / min / user | Contacts + Agents, 409 doublon |
| Anti-collision | safe_update + updated_stamp | Idempotence métier |
| Le bon cas | Support entreprise, entrepôt, multi-agents | Helpdesk Freshworks déjà en place |
Les trois (Zendesk, Freshdesk, Intercom) ne sont pas le même connecteur. Zendesk impose l'export incrémental et safe_update. Freshdesk facture les include. Intercom sépare conversation et ticket. C'est un arbitrage de cadrage.
Ce que nous mesurons sur une intégration Zendesk
Les autres API de support
Si Zendesk n'est pas le bon socle, ces options se discutent au cadrage.
ZendeskIntégration de l'API Zendesk dans votre systèmeCette page
FreshdeskTickets v2, contacts, include facturé, automations plutôt qu'un bus d'events.
IntercomConversations et tickets, région EU, webhooks SHA-1 via le Hub.On combine Zendesk avec
La stack qui entoure Zendesk sur nos projets.
Intégrateur Zendesk : vos questions
Un intégrateur Zendesk relie Zendesk à votre application, votre CRM et votre entrepôt, plutôt que de coller un widget. L'intégration API : authentification OAuth Bearer ou Basic email/token, création de tickets avec external_id, safe_update sur chaque PATCH partagé avec des automations, Incremental Export cursor pour le stock, webhooks HMAC pour le temps réel. On ne construit pas un job sur GET /tickets?page=. La partie sensible n'est pas le CRUD, c'est le plafond 30 updates / 10 min / ticket et le seau Suite partagé avec l'UI.
Aligner le token bucket sur le plan réel (Team 200, Growth et Professional 400, Enterprise 700, Enterprise Plus ou High Volume 2 500 / min). Agréger les updates ticket sous 30 / 10 min / agent. File par utilisateur à 5 / min sur create_or_update. Incremental à 10 / min (30 avec High Volume). Lire X-Rate-Limit et Retry-After. High Volume porte le plafond à 2 500, ce n'est pas un bonus empilable. Help Center a un seau séparé.
Parce que la documentation Tickets renvoie vers Incremental Export, et que le list au-delà de la page 500 tombe à 50 / min. L'export cursor-based est fait pour le stock : doublons time-based à filtrer (id + updated_at), pas de trou si on repart de end_time, données de la dernière minute exclues. Les tickets deleted restent exportés, puis SCRUBBED, puis tombent vers 120 jours. Un entrepôt qui ignore SCRUBBED n'est plus une source KYC.
Un premier flux utile, typiquement créer un ticket depuis un incident applicatif avec external_id, se livre en deux à trois semaines. Une chaîne webhooks, incremental, upsert CRM, portail Requests et anti-collision automation demande plutôt six à huit semaines : le mapping organisations et le RGPD pèsent autant que le code. Nous cadrons le périmètre en amont et vous donnons une estimation ferme avant de commencer.
Zendesk si le support entreprise est déjà le système d'enregistrement, et que vous voulez un entrepôt plus un bus d'events signé. Freshdesk si le helpdesk Freshworks est en place et qu'un CRUD tickets + contacts suffit, avec automations. Intercom si le produit vit dans le Messenger, tickets Inbox à côté des conversations, région EU. Traiter les trois comme le même connecteur est le piège du cadrage.
Un projet d'intégrateur Zendesk ?
Parlons-en. 30 minutes pour cadrer vos tickets, l'export incrémental et vous dire franchement ce qui est faisable.
Parler de mon projet Zendesk