DEVIS FICTIFDV-2026-0184
ACCEPTÉ- HT
- 8 400,00 €
- TVA
- 1 680,00 €
- TTC
- 10 080,00 €
API
Intégrateur Sellsy API : un devis ne devient facture que sur preuve
Dawap relie Sellsy à votre CRM, ERP, e-commerce, PSP et outils métier. Avant d’automatiser, nous séparons l’identité du client, l’accord commercial, la pièce validée et l’encaissement réel afin qu’un webhook tardif, un timeout ou une correction humaine ne transforme pas un dossier juste en faux solde.
- Un owner par transition
- V2 prioritaire, V1 bornée
- Paiement rapproché avant relance
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
Une intégration API Sellsy sur mesure relie CRM et facturation sans confondre accord, document et encaissement.
Dawap définit qui crée ou enrichit société, contact et opportunité, quand un devis peut devenir commande ou facture, comment un paiement est rapproché et quelle preuve autorise une reprise. L’API V2 est privilégiée pour un nouveau projet ; chaque dépendance encore couverte par la V1 est isolée, testée et documentée.
- Choisir l’accès API et les scopes selon le serveur, l’utilisateur, ses droits et ses licences.
- Corréler société, contact, opportunité, devis, facture, avoir et paiement avec des identifiants stables.
- Vérifier signature, redelivery et réconciliation des webhooks au lieu de traiter leur réception comme une clôture.
- Réagir aux erreurs de validation, droits, licence, objet non modifiable et limite API sans retry aveugle.
Quote-to-cash control room · scénario illustratif
Le devis promet. La facture engage. Le paiement doit encore être prouvé.
Les sociétés, montants, statuts, identifiants et horaires ci-dessous sont fictifs. Cette salle de contrôle illustre les décisions à signer entre CRM, Sellsy, ERP et PSP.
- 01IdentitéSociété retrouvéeOK
- 02AccordDevis acceptéOK
- 03PièceFacture relueUNIQUE
- 04CashPaiement à rapprocherCONTRÔLE
Client source
Maison Orion Services
Company fictiveEXT-COMP-8041
RAPPROCHÉE- ID Sellsy
- 183…742
- Contact
- CTR-91…A2
- Owner identité
- CRM
- Owner facturable
- Sellsy
Variante « Maison Orion » reconnue ; aucune seconde société créée.
Matching non silencieuxL’adresse diffère : le champ est conservé pour arbitrage, pas écrasé.
FILE ADVDocuments Sellsy
Une transition, deux preuves distinctes
corrélation QTC-8041
FACTURE FICTIVEFA-2026-0271
RETROUVÉE- HT
- 8 400,00 €
- TVA
- 1 680,00 €
- TTC
- 10 080,00 €
Unicité clientClé externe + matching
PASSTransition devisAcceptation retrouvée
PASSFacture uniqueTimeout neutralisé
PASSPreuve cashPSP + pièce + avoir
HOLDRelanceInterdite avant verdict
LOCK- Devis acceptéevent EST-184-A
- Facture demandéeattempt 01 · QTC-8041
- Timeout reçueffet inconnu
- Facture relueFA-2026-0271 existe
- Paiement isoléavoir récent · décision finance
Ce que la documentation confirme — et ce que votre compte doit encore prouver
Sellsy recommande l’API V2 pour les nouveaux projets ; la V1 reste nécessaire pour certaines opérations non encore couvertes et peut utiliser un accès OAuth 2.0 V2 avec le scope adapté.
Les accès personnel, privé ou public ne servent pas le même contexte ; droits et licence du collaborateur associé s’appliquent au token.
Le webhook HTTP est signé mais n’attend pas de réponse et ne gère pas les erreurs de livraison : déduplication et réconciliation restent nécessaires côté intégration.
Validation, autorisation, licence, objet non modifiable, quota et HTTP 429 doivent conduire à une décision bornée ; Sellsy recommande notamment de temporiser les appels et d’utiliser les traitements batch.
Premier lot recommandé
Un dossier, trois transitions, une balance et cinq échecs exercés.
Apportez le devis, la facture ou le paiement qui oblige aujourd’hui commerce, ADV et finance à comparer plusieurs écrans. Le cadrage rend la chronologie et la reprise défendables avant d’ajouter d’autres objets.
Quand quatre statuts racontent quatre histoires
Le devis est accepté, la facture existe et le paiement est reçu : le dossier peut pourtant rester faux.
Le risque ne vient pas seulement de l’appel API. Il vient du moment où CRM, Sellsy, ERP et PSP donnent chacun un sens différent au même client, au même document ou au même règlement.
01
Identité
Une société et un contact sont recréés sous une variante
Clé externe, rapprochement, owner de champ et règle de fusion précèdent toute création dans Sellsy.
02
Document
Un retry reproduit une facture déjà validée
La tentative est corrélée au devis, à la facture et à leur état courant avant d’autoriser une nouvelle mutation.
03
Encaissement
Le webhook paiement relance un dossier déjà corrigé
Le signal PSP reste une preuve à rapprocher, pas l’autorisation silencieuse de clôturer ou de réécrire la pièce.
Contrats quote-to-cash
Six contrats empêchent le CRM et la facturation de se corriger en boucle.
Sellsy expose sociétés, contacts, opportunités et documents commerciaux. Leur disponibilité dans une API ne décide ni de leur owner, ni de leur ordre, ni de la preuve nécessaire pour les rejouer.
La société précède le document
Clé externe, raison sociale, adresses, contacts et rapprochement sont stabilisés avant devis, commande ou facture.
Le token hérite d’un périmètre réel
Type d’accès, scopes, collaborateur, droits et licence sont vérifiés pour éviter une intégration qui fonctionne seulement avec un compte trop puissant.
Un statut ne revient pas en arrière par défaut
Proposition, devis, commande, facture, avoir et paiement suivent des transitions autorisées avec un owner et un motif.
V2 et V1 ne sont pas mélangées implicitement
La V2 est choisie en priorité ; toute opération encore dépendante de la V1 reste inventoriée et isolée derrière le middleware.
Le webhook déclenche une vérification
Signature, type d’objet, corrélation, état courant et éventuelle redelivery sont contrôlés avant de produire un effet.
La reprise relit pièce et règlement
Le connecteur retrouve document, paiement et décision humaine avant de rejouer une création, validation, relance ou clôture.
Méthode dossier–transition–preuve
Signer la chronologie avant de choisir les endpoints Sellsy.
Dawap part du dossier qui diverge, se duplique ou déclenche la mauvaise relance. Commerce, ADV, finance, support et IT nomment les identités, statuts, owners, pièces, règlements, erreurs et preuves. Les appels API sont ensuite affectés à des transitions déjà assumées.
Retrouver le client
Rapprocher société, contact et référence externe avant toute création.
Protéger le document
Refuser la mutation d’une pièce finalisée ou incohérente sans la masquer.
Prouver le paiement
Distinguer signal PSP, règlement Sellsy et état de rapprochement.
Reprendre sans relancer
Conserver tentative, non-action, erreur et décision sous le même dossier.
Premier lot Sellsy
Réconcilier un devis accepté, sa facture et son paiement avant d’ouvrir tous les flux.
On choisit un parcours, une société témoin, un devis, une facture et un règlement. Le lot est accepté lorsque chaque transition a un owner, que les identifiants se retrouvent après timeout et qu’une redelivery ne produit ni doublon ni relance injustifiée.
1 parcours
1 dossier client
3 transitions
1 balance
5 contre-tests
Sorties attendues
Carte CRM–Sellsy–ERP–PSP avec source, owner, identifiant et droit d’écriture par étape.
Contrat société–devis–facture–paiement : champs, statuts, transitions, blocages et preuve attendue.
Inventaire V2/V1 par opération avec accès, scopes, licence, payload, pagination et erreur à traiter.
Cinq contre-tests : doublon candidat, facture non modifiable, timeout, webhook redélivré et limite API.
Journal expurgé reliant dossier, IDs source/Sellsy/PSP, tentative, événement, décision et non-action.
Recette commerce–ADV–finance–support, balance attendu–appliqué–refusé–à reprendre, alertes et runbook.
Recette CRM–Sellsy–finance
Trois scénarios doivent aboutir à une décision métier, pas seulement à un code HTTP.
Ces scénarios et leurs valeurs sont illustratifs. Ils doivent être rejoués sur votre compte, vos licences, vos objets et votre comptabilité. Aucun projet public ci-dessous n’est présenté comme une intégration Sellsy livrée.
Le formulaire et le CRM proposent deux variantes du même client.
- Scénario terrain
- La raison sociale diffère légèrement et le contact possède une adresse déjà connue. Deux créations isolées produiraient une société en double avant le premier devis.
- Architecture
- Normalisation, clé externe, matching explicable, file de collision et décision humaine bornée.
- Livrable
- Deux fixtures d’identité, preuve de rapprochement, champ ignoré et journal de fusion.
- Décision
- Enrichir l’objet existant ou isoler le doute ; ne jamais créer sur un matching ambigu.
- Résultat vérifiable
- Une société Sellsy et une identité source conservées sans perte.
Le middleware ne sait pas si la pièce a déjà été créée.
- Scénario terrain
- La réponse se perd après l’appel. Un retry immédiat peut générer une seconde facture ou tenter de modifier un document déjà finalisé.
- Architecture
- Corrélation, relecture par identifiants, verrou de transition, statut courant et reprise séparée de la validation.
- Livrable
- Fixture réseau, trace avant–après, balance de documents et commande de reprise ciblée.
- Décision
- Retrouver la pièce et son état avant d’autoriser une nouvelle mutation.
- Résultat vérifiable
- Une facture unique reste rattachée au devis et à la tentative source.
Le PSP confirme après une correction manuelle de la finance.
- Scénario terrain
- Le règlement arrive après qu’un avoir ou une réaffectation a modifié le dossier. Appliquer le signal sans relire créerait un faux solde ou une relance incohérente.
- Architecture
- Signature, déduplication, référence PSP, relecture facture/avoir, balance et file de décision.
- Livrable
- Événement signé fictif, deux états de dossier, preuve de non-action et alerte finance.
- Décision
- Rapprocher si les montants et la pièce convergent ; sinon conserver le signal sans clôturer.
- Résultat vérifiable
- Le paiement reste traçable sans écraser la correction la plus fiable.
Sellsy, CRM, ERP, comptabilité ou PSP ?
Le bon owner dépend de la transition qui coûte, pas du nom de l’outil.
Cette offre possède le dossier Sellsy connecté. Les référentiels de gestion, écritures comptables, transactions PSP et parcours e-commerce gardent leurs responsabilités propres.
Le besoin traverse sociétés, opportunités, devis, factures ou paiements Sellsy
L’offre cadre les objets Sellsy, l’accès API, les transitions, webhooks, erreurs et reprises.
Le besoin part du stock, des achats, de la production ou de la logistique
Le hub ERP possède le référentiel opérationnel et le choix du système de gestion.
Le besoin part des écritures, journaux, clôtures ou obligations fiscales
L’univers Finance possède la vérité comptable ; Sellsy transmet des pièces et états bornés.
Frontières de responsabilité
Relier Sellsy sans faire porter tous les rôles au même système.
Sellsy porte le cycle commercial documenté ; CRM, ERP, Paiements et e-commerce gardent leurs propres décisions et preuves.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
Questions d’achat
Questions fréquentes avant une intégration Sellsy API
Réponses sur API V2/V1, accès, objets CRM, devis, factures, paiements, webhooks et premier lot.
01Que couvre une intégration API Sellsy sur mesure ?
Elle relie sociétés, contacts, opportunités, devis, commandes, factures, avoirs ou paiements Sellsy à votre CRM, ERP, e-commerce, PSP, comptabilité ou application métier avec identifiants, règles, traces et reprises.
02Faut-il utiliser l’API V2 ou l’API V1 Sellsy ?
Sellsy recommande la V2 pour les nouveaux projets, mais précise que certaines possibilités restent en V1. Le cadrage inventorie chaque opération, privilégie la V2 et isole les dépendances V1 réellement nécessaires.
03Quel accès API Sellsy choisir ?
L’accès personnel convient notamment au serveur-à-serveur, le privé à une application client–serveur et le public aux partenaires validés par Sellsy. Les scopes, droits, licences, rotation et continuité du collaborateur associé doivent être vérifiés.
04Comment éviter un doublon de société ou de facture ?
On stabilise une clé externe, conserve la corrélation et relit l’objet Sellsy avant toute nouvelle mutation. Un matching ambigu ou une pièce déjà finalisée sort du retry automatique.
05Peut-on faire confiance à un webhook Sellsy pour clôturer un dossier ?
Le webhook est un signal à authentifier, dédupliquer et rapprocher de l’état courant. Comme la documentation indique qu’il n’attend pas de réponse et ne gère pas ses erreurs, une réconciliation complémentaire reste indispensable pour les effets sensibles.
06Quel premier lot Sellsy recommandez-vous ?
Un parcours, une société, un devis, une facture et un paiement. On exerce doublon, document non modifiable, timeout, redelivery et limite API avant d’ajouter d’autres objets ou automatisations.
Sellsy API · CRM · facturation
Votre prochain dossier Sellsy peut-il expliquer son devis, sa facture, son paiement et sa reprise ?
Dawap peut cadrer ce dossier témoin puis construire le middleware, les traces et le run qui protègent commerce, ADV, finance et support jusque dans les timeouts et corrections humaines.
Auditer mon flux Sellsy