Sellsy concentre des flux clés pour les équipes business: gestion CRM, devis, commandes, facturation et suivi de la relation client. Dans les projets multi-outils (e-commerce, ERP, PIM, BI), la moindre incohérence sur les identifiants clients, les statuts documentaires ou les montants peut impacter toute la chaîne opérationnelle.
Notre SDK Sellsy sous Symfony centralise l’authentification, les conventions de pagination, le mapping des objets métiers et la normalisation des erreurs. On évite ainsi les intégrations ponctuelles dispersées dans le code applicatif.
Vue d’ensemble: Intégration API.
L’API Sellsy permet de couvrir des cas d’usage variés, mais la difficulté n’est pas l’appel HTTP en lui-même. Le vrai sujet est la cohérence métier: cycle de vie des devis/commandes, synchronisation des contacts, fiscalité, et alignement des référentiels entre systèmes.
Nous séparons explicitement ce qui est contractuel (champs requis, formats, statuts admissibles) de ce qui est illustratif (exemples de payloads). Cette distinction évite de coupler les équipes à des conventions internes non garanties par l’API.
Nous cadrons systématiquement les préconditions/postconditions: objet source requis, statut attendu côté Sellsy, règles de transformation autorisées et validations de cohérence avant accusé de traitement.
Le SDK suit une architecture en couches: `SellsyAuthProvider`, `SellsyHttpClient`, `SellsyDomainAdapters`, `SellsyErrorMapper`, `SellsyTelemetry`. Symfony apporte l’injection de dépendances, la configuration par environnement et les politiques transverses de résilience.
Les adapters sont orientés métier: `CompanyAdapter`, `ContactAdapter`, `OpportunityAdapter`, `QuoteAdapter`, `OrderAdapter`, `InvoiceAdapter`, `PaymentAdapter`. Cette découpe limite l’effet de bord quand un endpoint évolue.
final class SellsyOrderAdapter
{
public function __construct(
private SellsyHttpClient $client,
private SellsyErrorMapper $errors
) {}
public function createOrder(array $payload, string $idempotencyKey): array
{
return $this->client->post(
'/v2/sales/orders',
$payload,
headers: ['X-Idempotency-Key' => $idempotencyKey]
);
}
}Chaque écriture sensible passe par une API dédiée, avec clé d’idempotence et mapping d’erreurs centralisé. C’est ce qui rend le comportement prédictible quand on passe en volumétrie.
sellsy_sdk:
http:
base_uri: '%env(SELLSY_API_BASE_URI)%'
timeout:
read_seconds: 8
write_seconds: 18
retries:
read_max: 2
write_max: 1
backoff_ms: [250, 800]Exemples illustratifs, à adapter au modèle de données Sellsy de votre instance.
Les exemples ci-dessous sont illustratifs. Le contractuel dépend de la version API cible, des modules activés et des règles métiers propres au compte Sellsy.
{
"externalId": "COMP-002145",
"name": "Alphacore Industrie",
"vatNumber": "FR87123456789",
"contacts": [
{
"externalId": "CTC-9981",
"firstName": "Camille",
"lastName": "Durand",
"email": "camille.durand@alphacore.fr",
"phone": "+33 1 55 20 10 30"
}
]
}POST /v2/companies/upsert HTTP/1.1
Host: [SELLSY_HOST]
Authorization: Bearer [ACCESS_TOKEN]
Content-Type: application/json
X-Correlation-Id: 17a0a2ad-3162-405d-a261-c7417f53f488
X-Idempotency-Key: 44f5c7d7-2c35-4f18-bbbf-2eeb57d34aab{
"quoteNumber": "DEV-2026-00412",
"companyExternalId": "COMP-002145",
"currency": "EUR",
"issueDate": "2026-02-19",
"lines": [
{"sku": "SVC-INT-API", "qty": 3, "unitPriceExclTax": 950.00, "taxCode": "TVA20"}
]
}{
"status": "CREATED",
"sellsyDocumentId": "Q-2026-000784",
"correlationId": "17a0a2ad-3162-405d-a261-c7417f53f488",
"warnings": []
}{
"sourceQuoteId": "Q-2026-000784",
"orderNumber": "CMD-2026-00231",
"invoiceNumber": "FAC-2026-00154",
"autoPostAccounting": true
}Après chaque transition documentaire, le SDK relit le statut et les totaux pour garantir la cohérence métier. Cette vérification post-écriture est indispensable pour sécuriser la chaîne finance.
Séquence type: validation du payload, upsert référentiels (société/contact), création documentaire, transition d’état, contrôle des écritures et accusé final. Les étapes sont rejouables sans duplication.
En multi-entités, nous segmentons les traitements par contexte business (société, devise, unité commerciale) afin d’éviter les contaminations inter-flux et de simplifier les reprises ciblées.
Queue naming recommandé:
- erp.sellsy.crm.[business_unit]
- erp.sellsy.quote.[business_unit].[currency]
- erp.sellsy.billing.[business_unit].[currency]Le SDK applique des timeouts par type d’opération, un budget de retries borné et une clé d’idempotence sur les écritures. Les erreurs sont classées en trois catégories: technique, contrat, métier.
enum SellsyErrorClass: string
{
case TECHNICAL = 'technical';
case CONTRACT = 'contract';
case BUSINESS = 'business';
}
final class RetryPolicyDecider
{
public function shouldRetry(SellsyErrorClass $class): bool
{
return $class === SellsyErrorClass::TECHNICAL;
}
}Une erreur de contrat n’est jamais rejouée automatiquement: elle doit être corrigée à la source pour éviter une boucle d’échec et une dette opérationnelle inutile.
Nous combinons tests unitaires (mapping/validation), tests d’intégration API (nominaux et dégradés) et scénarios non-régression sur transitions critiques du cycle devis -> commande -> facture.
Référence utile: Tests API, stratégie et bonnes pratiques.
Matrice de test minimale:
1) Nominal: société + contact -> devis -> commande -> facture
2) Dégradé réseau: timeout en création devis + reprise idempotente
3) Dégradé contrat: champ fiscal manquant -> rejet actionnable
4) Dégradé métier: transition d’état interdite -> quarantaine
5) Non-régression: relance batch déjà traité -> aucun doublonPostman sert à qualifier rapidement les endpoints, partager des scénarios de recette et documenter les assertions attendues avant passage en CI.
Voir: Postman pour industrialiser vos tests API.
{
"name": "sellsy-sdk-create-quote",
"event": [
{
"listen": "test",
"script": {
"exec": [
"pm.response.to.have.status(200);",
"pm.expect(pm.response.json().status).to.eql('CREATED');",
"pm.expect(pm.response.responseTime).to.be.below(1500);"
]
}
}
]
}Chaque appel est corrélé (trace id), journalisé (endpoint, durée, statut, retries) et supervisé via des dashboards orientés run et qualité métier.
Complément: Observabilité et runbooks API.
Jeu de métriques recommandé:
- api_call_duration_ms{endpoint,operation}
- api_error_total{class,endpoint}
- integration_backlog_size{queue}
- replay_total{reason}
- reconciliation_gap_total{module}Chaque alerte est liée à un runbook court: diagnostic initial, vérifications, action de reprise et seuil d’escalade.
Vue d’ensemble: Présentation des SDK API ERP développés par Dawap.
SDK API ERP Microsoft Dynamics 365
La performance d’une intégration Sellsy repose sur un cadre solide: contrat de données explicite, gestion d’erreurs actionnable, tests réalistes et observabilité continue.
Le cadrage initial doit expliciter les responsabilités: validation des règles métier, ownership run, stratégie de reprise et gouvernance des évolutions API. Sans ce cadre, le coût opérationnel augmente vite.
Pour approfondir: Intégration API ERP Sellsy et notre offre Intégration API.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous
Les flux Odoo exigent une lecture fine de JSON-RPC, des modèles métier et des règles de transition documentaires. Ce guide détaille comment Dawap structure un SDK Symfony pour synchroniser clients, commandes, factures et stocks avec idempotence, retries maîtrisés et traçabilité run.
SAP implique des contraintes élevées sur la volumétrie, la cohérence des données et la robustesse des workflows critiques. Nous y détaillons notre SDK Symfony pour orchestrer les flux logistiques et financiers avec contrôle d'état strict, résilience réseau et supervision orientée production.
Dynamics 365 nécessite des échanges API REST sécurisés et cohérents sur plusieurs domaines métier simultanément. Ce guide explique notre SDK Symfony pour synchroniser ventes, clients, stocks et finance, tout en conservant une observabilité fine et une gestion d'incidents pilotable.
Les projets Divalto demandent de concilier contraintes terrain, flux commerciaux et exigences logistiques. L'article présente notre SDK Symfony avec mappings versionnés, stratégie de retry adaptée et normalisation des échanges pour stabiliser les opérations au quotidien.
Nous accompagnons les équipes produit et techniques dans la conception, l’intégration et l’industrialisation d’APIs. Notre mission : construire des architectures robustes, sécurisées et évolutives, alignées sur vos enjeux métier et votre croissance.
Vous préférez échanger ? Planifier un rendez-vous