Construisez sur un CRM API-first dès le premier jour.
Chaque enregistrement, chaque pipeline, chaque automatisation est accessible sur /v1 — exactement le même moteur que celui qui fait tourner l’application. Clés API pour vos propres scripts, OAuth 2.0 pour les applications partenaires, et des webhooks qui ne perdent pas d’événements.
Pas un onglet d’intégrations ajouté après coup — le moteur lui-même.
La plupart des CRM exposent une API minimaliste et en retard par rapport au « vrai » produit. L’application web, l’application mobile et l’API de GENECRM sont trois clients d’un seul back-end — l’API ne peut donc jamais prendre du retard sur ce que vous voyez à l’écran.
Rien dans l’application n’est cloisonné par rapport à l’API — les mêmes enregistrements, la même validation et les mêmes automatisations alimentent l’interface et chaque appel /v1.
Le web, l’application native iOS/Android et vos intégrations parlent tous au même back-end — construisez une fois, ça se comporte de façon identique partout.
Chaque réponse est ancrée dans vos données réelles, isolées par locataire. Aucune IA cachée ne réécrit vos enregistrements — l’automatisation et le copilote GENE n’agissent que sur ce que vous autorisez.
Le flux OAuth 2.0 client-credentials associé à un octroi d’échange utilisateur a été conçu pour les applications partenaires qui intègrent GENECRM en headless derrière leur propre interface.
Une clé que vous générez vous-même, cantonnée comme vous le souhaitez
Générez une clé depuis Paramètres → Développeurs — sans ticket de support, sans attente. Cantonnez-la en lecture seule pour une intégration de reporting ou en lecture+écriture pour ce qui crée et met à jour des enregistrements, et révoquez-la instantanément si elle fuite.
- Libre-service — créez, faites pivoter et révoquez les clés depuis les paramètres de l’application
- Cantonnée en lecture ou lecture+écriture ; chaque clé se résout en un locataire et une identité de service
- Envoyée comme en-tête X-API-Key sur chaque requête — pas de session, pas de cookies
- L’usage de chaque clé est détaillé séparément dans GET /v1/usage
Client-credentials pour les applications qui agissent pour leur propre compte
Enregistrez un client OAuth, échangez son client_id/secret contre un jeton d’accès de courte durée et rotatif, puis utilisez-le comme un jeton Bearer normal sur n’importe quel point d’accès /v1 — l’alternative adaptée à l’entreprise face à une clé API statique qui traînerait dans le code d’un partenaire.
- POST /oauth/token — grant_type=client_credentials + client_id + client_secret
- Renvoie un JWT cantonné de courte durée : { access_token, token_type: "Bearer", expires_in }
- Utilisez-le comme Authorization: Bearer <token> sur n’importe quelle ressource /v1
- Pour les applications intégrées/partenaires, échangez-le à nouveau contre l’identité d’un utilisateur réel — voir ci-dessous
Une seule forme, une seule frontière, chaque ressource sous /v1.
Chaque ressource ci-dessous partage la même forme de requête et de réponse, la même pagination (?limit=&offset=), et la même frontière de sécurité au niveau des lignes — la liste et la création ne renvoient que les lignes de votre locataire, un point c’est tout. La couverture en écriture varie selon la ressource ; la spécification OpenAPI en donne la liste exacte.
Événements signés, un journal de livraison, et rien de perdu
Abonnez une URL aux événements qui vous intéressent — crm.contact.create, crm.lead.create, crm.opportunity.update, et plus. Chaque livraison est signée HMAC afin que vous puissiez faire confiance à la charge utile, chaque tentative est journalisée, et les échecs atterrissent dans une file d’attente de lettres mortes que vous pouvez rejouer.
- POST /v1/webhooks — { url, events: [...] } renvoie un secret de signature, affiché une seule fois
- Chaque livraison porte X-GeneCRM-Signature: sha256=<hmac> sur le corps brut
- Historique complet des livraisons sur GET /v1/webhooks/deliveries
- Les livraisons échouées sont retentées jusqu’à 5 fois, puis restent dans GET /v1/webhooks/events/failed pour être rejouées
Mesuré par plan, visible en temps réel.
Les limites de débit par minute sont échelonnées par plan et appliquées en périphérie ; un quota d’appels mensuel séparé est mesuré par locataire. Les deux sont interrogeables, si bien que rien dans votre usage n’est une surprise.
Premium ≈ 120 req/min, Pro ≈ 600 req/min — dépassez-la et vous obtenez 429 avec un en-tête Retry-After, pas un rejet silencieux.
Un quota d’appels mensuel séparé est mesuré par locataire. Une fois épuisé, les appels suivants renvoient HTTP 402 Payment Required jusqu’à la réinitialisation de la période ou une mise à niveau.
L’usage de la période en cours par rapport à la limite de votre plan, détaillé par clé API — construisez votre propre tableau de bord ou vérifiez simplement avant de déployer.
Les limites de votre plan et les fonctionnalités cantonnées activées — y compris api_access lui-même, disponible à partir de Pro.
Une spécification à partir de laquelle générer un client, dans n’importe quel langage
L’API complète est décrite par une spécification OpenAPI/Swagger générée à partir du même schéma qui sert l’API — elle ne peut pas se désynchroniser. Associez-la à un guide de prise en main et à une gestion des clés en libre-service, et vous passez votre premier appel en quelques minutes.
- Spécification OpenAPI lisible par machine sur /openapi.json — générez un client pour n’importe quel langage
- Clients de référence Python et TypeScript, plus un utilitaire de vérification de webhook
- Un guide de prise en main détaille votre première clé, votre premier appel et votre premier webhook
- Gérez vous-même les clés et les clients OAuth : Paramètres → Développeurs, sans ticket de support
Exécutez GENECRM au cœur de votre propre produit.
Les intégrations partenaires et plateformes n’ont pas à partager un seul compte de service. Échangez le jeton d’application de votre OAuth contre l’identité d’un utilisateur réel, et chaque action lui est attribuée — avec la garantie complète d’isolation par locataire intacte.
L’échange d’intégration en trois étapes
- 1. Jeton d’application. Votre back-end échange son client_id/secret OAuth contre un jeton Bearer cantonné à l’application via
POST /oauth/token. - 2. Échange utilisateur. Votre back-end appelle
POST /v1/auth/exchangeavec le jeton d’application ainsi que l’identifiant externe et l’e-mail de l’utilisateur connecté — GENECRM trouve ou crée cet utilisateur et renvoie son propre jeton d’accès. - 3. Proxy, par utilisateur. Votre interface appelle
/v1/**via votre propre proxy avec le jeton de cet utilisateur — chaque écriture est attribuée à la personne réelle, cantonnée à son cabinet par la sécurité au niveau des lignes.
Une seule API versionnée, deux moyens d’y accéder — clés API ou OAuth 2.0 — chaque ressource sous un chemin unique, des webhooks signés auxquels vous pouvez faire confiance, et un usage visible avant de heurter un mur.
Les questions que se posent vraiment les développeurs.
Les clés API sont la voie rapide pour vos propres scripts et outils internes : générez-en une dans Paramètres → Développeurs et envoyez-la comme X-API-Key. OAuth 2.0 client-credentials est destiné à une application ou intégration partenaire agissant pour son propre compte — un jeton Bearer rotatif de courte durée plutôt qu’un secret statique dans chaque requête.
Les limites de débit par minute sont échelonnées par plan (Premium ≈ 120 req/min, Pro ≈ 600 req/min) et renvoient 429 avec un en-tête Retry-After. Le quota d’appels API mensuel séparé est mesuré indépendamment — une fois épuisé, les appels suivants renvoient 402 Payment Required jusqu’à la réinitialisation de la période ou une mise à niveau.
Chaque livraison est signée : l’en-tête X-GeneCRM-Signature porte sha256=<hmac>, un HMAC-SHA256 du corps brut de la requête utilisant le secret de votre point d’accès (affiché une seule fois à la création). Recalculez-le et comparez-le avec une vérification à temps constant avant de faire confiance à la charge utile — ne faites jamais confiance à une livraison non signée ou ne correspondant pas.
Les livraisons sont retentées automatiquement jusqu’à 5 fois avec un délai croissant. Si elles échouent encore, l’événement atterrit dans la file d’attente de lettres mortes (GET /v1/webhooks/events/failed) et vous pouvez le rejouer à la demande une fois votre point d’accès de retour — aucun événement perdu.
Chaque espace de travail que vous créez est déjà un locataire isolé : un second espace de travail vous sert donc d’environnement de développement — développez et testez dessus avec ses propres clés, puis pointez votre intégration vers votre espace de travail de production une fois prêt. Il n’y a aucune distinction entre clés de test et clés de production à gérer.
Chaque ressource se trouve sous /v1. Nous ajoutons des champs et des points d’accès de manière rétrocompatible au sein d’une version ; un changement cassant obtient une nouvelle version plutôt que de modifier silencieusement /v1 sous vos pieds.
Le mobile utilise son propre octroi par mot de passe : POST /v1/auth/token avec e-mail + mot de passe renvoie un jeton d’accès de courte durée ainsi qu’un jeton de rafraîchissement rotatif, rafraîchi sans redemander à l’utilisateur de se reconnecter. C’est un flux distinct des clés API et des applications OAuth, cantonné à l’utilisateur connecté.
GET /v1/usage renvoie l’usage de votre période en cours par rapport à la limite de votre plan, détaillé par clé API, et GET /v1/entitlements renvoie les limites de votre plan et les fonctionnalités cantonnées activées — comme api_access lui-même.