Intégration API Sellsy
Nous développons votre connecteur Sellsy
Nous branchons Sellsy dans votre SaaS : le configurateur pousse le devis, la facture payée ouvre l'accès, l'abonnement met à jour le tiers. Commerce et produit partagent le même dossier, sans double saisie.
- Équipe produit senior
- connecteurs CRM et facturation en production
- du cadrage au monitoring
Pourquoi intégrer Sellsy à son application et que peut-on connecter à Sellsy ?
Sellsy est un CRM et outil de gestion commerciale français (devis, factures, tiers, ventes). On l'intègre pour qu'il vive dans votre plateforme : configurateur qui pousse le devis, facture payée qui ouvre l'accès produit, abonnement qui met à jour le tiers, SAV et commercial sur le même dossier. Pas de ressaisie entre l'outil métier et Sellsy. Le travail, c'est le mapping documents/TVA, l'anti-doublon SIRET et la réconciliation, parce que les notifications Sellsy ne retentent pas si votre serveur est indisponible.
Ce que Sellsy change dans votre plateforme
Le configurateur pousse le devis
Un estimate Sellsy, relance et PDF restent dans Sellsy. Le commercial ne retape pas les lignes du produit.
La facture payée ouvre l'accès
La facture payée ouvre l'accès produit. Sans tableur de lettrage. Une reprise rattrape l'événement perdu.
L'abonnement met à jour le tiers
Plan, MRR, échéance poussés depuis le produit. Le commercial filtre les comptes à risque sans export CSV.
SAV et commercial voient le même dossier
companies dédupliquées par SIRET. Relances, avoirs et tickets partent du même tiers, pas de deux bases parallèles.
Ce que ça change dans votre produit
La technique au service d'un résultat mesurable : configurateur → devis, paiement → accès, une vérité partagée.
Sellsy reste la source commerciale
Devis, factures, relances et PDF vivent dans Sellsy. Votre application reste l'outil métier. Personne n'a à changer de logiciel.
Le paiement ouvre l'accès, même si une notif est perdue
La facture payée provisionne le compte. Une file de reprise rattrape l'événement manqué : le client n'attend pas qu'on relance à la main.
Le connecteur ne meurt pas avec un commercial
L'accès technique n'est pas collé au siège d'un vendeur. Quand quelqu'un part, le flux devis → facture → accès continue.
Prêt pour la facture électronique
Mentions, TVA et type de vente sont cadrés avant d'écrire la première facture. Vous évitez de découvrir le trou le jour de la réforme.
Comment nous livrons votre connecteur Sellsy
Cadrage
Où Sellsy entre dans votre produit : configurateur, paiement, abonnement, SAV. Personnel vs Privé/Public, collaborateur technique, scopes, réforme facture électronique.
Mapping
Tiers, lignes, TVA, sale_type, champ custom d'idempotence. C'est l'étape qui décide de la réussite.
Développement et recette
OAuth, refresh 3600 s, signature SHA-1, traitement async, réconciliation. Recette sur un compte sandbox, pas le CRM de production.
Monitoring
Alerte sur signature invalide, job de rattrapage, refresh en coffre. Vous savez qu'un flux est cassé avant vos commerciaux.
Ce que l'API apporte à votre plateforme
- Tiers et catalogue
- companies, individuals, items, staffs. Recherche dédiée sur les documents. Un SIRET unique évite les doublons de relance.
- Documents de vente
- estimates, invoices, orders, deliveries, credit-notes, paiements rattachés, subscriptions. Search par type de document.
- Webhooks HTTP et Slack
- Admin seulement. relatedtype large (third, estimate, invoice, project, ticket…). Corps form-urlencoded, signature SHA-1.
- Comptabilité et e-invoicing
- Journal exposé, sale_type sur les documents de vente, préférences de réforme. Mapping à faire avant le premier POST /invoices.
Le vocabulaire d'une intégration Sellsy
- Personnel, Privé, Public
- Trois types d'accès API v2. Personnel : client credentials, un compte. Privé et Public : authorization code + PKCE, pour une app. Les scopes se cochent un par un.
- Collaborateur lié
- Le niveau de privilège du token suit ce collaborateur. S'il est désactivé, les tokens meurent. Compte de service dédié.
- third
- Société client, prospect ou fournisseur dans les webhooks. Côté API v2 : companies / individuals.
- X-Webhook-Signature
- sha1(sign_key + body brut), pas HMAC-SHA256. Le body doit rester form-urlencoded, non reparsé.
- Pas de retry
- Le webhook n'attend pas de réponse et ne gère pas les erreurs. Downtime = événement perdu. Réconciliation par API obligatoire.
- sale_type
- Champ des documents de vente lié à la réforme facture électronique 2026. À mapper avant le premier POST /invoices, pas après.
Les contraintes réelles d'une intégration Sellsy
Le webhook jette l'événement
Pas de retry, pas d'attente de 2xx. Un downtime de 30 secondes = perdu. La réconciliation par API n'est pas un filet, c'est le design.
Le token meurt avec le collaborateur
Compte technique admin, scopes minimaux, procédure si le salarié porteur part. Client credentials réservé aux accès Personnels, pas à une app multi-clients.
Signature SHA-1 sur body brut
X-Webhook-Signature = SHA1(SIGN_KEY + BODY). Comparer avec hash_equals. Un body reparsé en JSON casse la signature, il faut le brut form-urlencoded.
L'onglet dit encore « bêta »
En mars 2026 l'UI parle d'API V2 (bêta) alors que le changelog est long et que v1 se déprécie. On cadre la version avec Sellsy avant une garantie de stabilité.
Sellsy ou HubSpot, et ce que ça implique
Sellsy réunit CRM et facturation. HubSpot réunit CRM et marketing. Le choix se fait sur l'outil déjà en place, rarement sur la technique.
| Critère | SellsyCette page | HubSpotCRM marketing |
|---|---|---|
| Périmètre | CRM plus devis, factures, commandes | CRM plus marketing, tickets, workflows |
| API | REST v2, portail dans le produit | REST publique, écritures groupées de 100 |
| Authentification | OAuth Personnel / Privé / Public, PKCE | App privée ou app publique OAuth |
| Temps réel | Webhooks sans retry, signature SHA-1 | Webhooks v4 signés HMAC, retries |
| Facture électronique | sale_type, mentions, sujet 2026 | Hors cœur, souvent un autre outil |
| Effort d'intégration | Moyen, piège = webhooks et token collaborateur | Faible à moyen, piège = quota et contacts marketing |
| Le bon cas | PME française, devis et factures dans le CRM | SaaS qui veut inbound, workflows et un CRM produit |
Nous ne revendiquons ni partenariat ni marketplace Sellsy : nous développons sur l'API v2 documentée.
Ce que nous mesurons sur un projet Sellsy
Les autres CRM que nous intégrons
Le choix se fait sur le CRM déjà en place chez vous, rarement sur la technique.
SellsyNous développons votre connecteur SellsyCette page
HubSpotAPI REST très documentée, webhooks signés, bon cas pour brancher un produit vite et proprement.
SalesforceLes gros volumes et les organisations complexes, Platform REST, CDC, quota d'org.
PipedrivePipeline PME, API v2, webhooks HTTP. Budget de jetons partagé par tout le compte.On combine Sellsy avec
La stack qui entoure Sellsy sur nos projets.
Intégration Sellsy : vos questions
On la branche sur vos touchpoints produit : configurateur, paiement, abonnement, SAV. Accès v2 dans le Portail Développeur : Personnel pour un dossier unique (client credentials), Privé ou Public pour une app (authorization code + PKCE). Compte collaborateur technique, scopes minimaux. On mappe tiers et documents, on vérifie X-Webhook-Signature sur le body brut, on accuse vite côté nôtre (même si Sellsy n'attend pas), et on réconcilie par /invoices/search parce que les événements se perdent. La difficulté réelle n'est pas l'appel HTTP, c'est le retry que Sellsy ne fait pas et le mapping e-invoicing.
Pour déployer Sellsy et former l'équipe commerciale, un partenaire Sellsy a du sens. Pour faire vivre Sellsy dans votre plateforme (configurateur → devis, paiement → accès), ce qui compte est l'expérience des connecteurs de facturation : OAuth, webhooks sans retry, TVA, sale_type. Nous ne revendiquons ni partenariat ni marketplace : nous développons sur l'API v2 documentée, et nous travaillons volontiers avec qui administre déjà votre compte.
Cela dépend du nombre de documents, du sens des flux et de l'état du référentiel tiers. Un devis poussé depuis un configurateur se chiffre bien plus bas qu'une chaîne complète avec portail factures, time tracking et export journal. La réforme facture électronique pèse sur le mapping, pas seulement sur le calendrier légal. Nous cadrons le périmètre en amont et donnons une estimation ferme, avant le premier POST.
Ils partent vite, ils ne sont pas fiables. Sellsy ne retry pas et n'attend pas de 2xx. Un handler down 30 secondes perd l'événement. Nous vérifions la signature SHA-1 sur le body brut, traitons en asynchrone, et collons un job de réconciliation sur les documents mis à jour. Sans ce filet, « temps réel » est un mot trop fort, et le devis d'intégration le dit clairement dès le cadrage. C'est un choix d'architecture.
Oui : POST /v2/estimates, tiers dédupliqué, lignes, TVA, sale_type. Idempotence par id Sellsy persisté et clé métier en champ custom. Tester la limite de lignes sur un compte sandbox : le changelog a retiré la limite des specs tout en gardant une limite backend. On ne promet pas un devis à 5 000 lignes sans ce test, et on ne pousse pas un POST /invoices avant d'avoir mappé la réforme facture électronique.
Un projet d'intégration Sellsy ?
Parlons-en. 30 minutes pour cadrer où Sellsy entre dans votre plateforme (configurateur, paiement, abonnement) et vous dire franchement ce qui est faisable.
Parler de mon projet Sellsy