Intégrateur API Odoo : ERP, e-commerce et middleware sur mesure
Dawap relie Odoo à votre e-commerce, marketplace, WMS, PIM, CRM ou outil métier quand un connecteur ne suffit plus à protéger la commande, le stock et la facture. Nous cadrons la version, les modules, les droits, la source de vérité de chaque objet et le comportement après timeout avant d’ouvrir les écritures dans l’ERP.
Réponse courte
Odoo API doit cadrer les objets ERP avant les appels techniques.
API Odoo ou Odoo API peut passer par JSON-2, XML-RPC/JSON-RPC legacy, modules spécifiques ou couche dédiée selon version et périmètre. Dawap vérifie les objets commandes, stocks, factures, produits, clients, droits, modules et reprises avant de connecter e-commerce, marketplaces, WMS, PIM, CRM ou outils métier.
- Identifier version Odoo, modules, droits, objets, API cible et dépendances avec les personnalisations existantes.
- Protéger commandes, stocks, factures, clients, produits, retours, paiements et écritures contre doublons et écarts.
- Prévoir idempotence, logs, replay, quarantaine, supervision et runbook pour tenir en production.
Object write gate · scénario illustratif
La commande existe déjà. Le retry doit le prouver avant d’écrire une seconde fois.
L’entreprise, les identifiants, les montants et les événements ci-dessous sont fictifs. Ce poste de contrôle montre comment une intégration Odoo arbitre commande, picking et facture après une réponse réseau ambiguë.
Un timeout après confirmation, quatre objets à relire
/json/2/sale.order/search_read{ "domain": [["client_order_ref", "=", "WEB-9218"]], "fields": ["name", "state", "picking_ids", "invoice_ids"] }
Cinq preuves avant de libérer le flux
- 01IdentitéWEB-9218 ↔ SO-4821PASS
- 02Sociétécompany_id FrancePASS
- 03Logistiquepicking déjà réservéPASS
- 04Financeinvoice_ids à expliquerHOLD
- 05Repriseétape autorisée bornéeLOCK
shop-fr:sale.order:WEB-9218:confirm:v3
La clé facilite la décision ; elle ne rend pas automatiquement une méthode Odoo idempotente.
Trois incidents, trois gestes différents
Rattacher l’identifiant Odoo et poursuivre après contrôle aval.
RAPPROCHERGeler l’écriture et faire décider la finance après relecture.
ARBITRERCorriger droit ou contrat ; ne pas élargir le compte à l’aveugle.
BORNER- Commande reçueWEB-9218 · hash conservé
- Confirmation envoyéeréponse réseau perdue
- sale.order reluSO-4821 retrouvée
- Picking rapprochéWH/OUT/01842 réservé
- Facture à qualifierreprise suspendue
Ce que l’API garantit — et ce que le middleware doit décider
Odoo 19 documente des appels POST /json/2/<model>/<method> avec arguments nommés et clé API Bearer.
Les droits d’accès, règles d’enregistrement et accès aux champs de l’utilisateur restent appliqués à l’appel.
La page /doc de la base expose les modèles, champs et méthodes disponibles, y compris les extensions installées.
XML-RPC et JSON-RPC sont dépréciés depuis Odoo 19 ; leur retrait est annoncé pour Odoo 22 et Odoo Online 21.1.
Premier lot recommandé
Une commande, son picking, sa facture possible et cinq échecs exercés en recette.
Apportez le dossier Odoo qui oblige aujourd’hui commerce, logistique et finance à comparer plusieurs écrans. Le cadrage fixe objets, droits, corrélation, portes d’écriture et preuve de reprise avant d’étendre le flux.
Signaux terrain
Les signaux qui justifient un vrai chantier.
Le premier cadrage sert à distinguer le symptôme visible de la cause qui fragilise réellement le business ou le run.
Qualifier l’API Odoo selon version, modules et objets métier
Un projet Odoo API fiable distingue JSON-2, RPC legacy, modules personnalisés, droits, objets ERP et trajectoire de migration avant de coder.
Brancher Odoo au commerce sans créer de doublons
Commandes, stocks, factures, produits, clients, retours et paiements doivent porter des clés métier, des contrôles et des règles de replay.
Confier le flux à un intégrateur quand Odoo devient le cœur de gestion
Le besoin dépasse le connecteur quand chaque écriture doit préserver ventes, logistique et finance entre Odoo et plusieurs applications.
Diagnostic Odoo
Quand Odoo devient le point de friction entre vente, stock et finance
Un connecteur Odoo fragile se voit vite : commandes en doublon, stocks qui divergent, factures bloquées, modules custom difficiles à appeler, droits mal cadrés ou reprises impossibles à expliquer aux métiers.
Commandes et statuts
Import e-commerce ou marketplace, acceptation, lignes, taxes, frais, statuts, tracking et rapprochement avec les documents Odoo.
Stocks et entrepôts
Stock disponible, réservations, multi-entrepôts, mouvements, ruptures, buffers canal et synchronisation des quantités diffusables.
Factures et écritures
Création de factures, avoirs, paiements, statuts comptables, pièces justificatives et cohérence avec les règles de gestion.
Produits et référentiels
SKU, variantes, catégories, taxes, prix, clients, adresses et mappings entre Odoo, PIM, boutique ou marketplace.
Reprises contrôlées
Files, idempotence, replay par objet métier, quarantaine, historique des payloads et correction sans double écriture.
Droits et modules spécifiques
Gestion des accès, contraintes de version, modules custom, endpoints dédiés et sécurité des échanges avec Odoo.
Méthode
On traite Odoo comme un cœur de gestion, pas comme un simple endpoint
Avant de coder, on clarifie la source de vérité par objet : produit, stock, commande, facture, client, paiement, retour. Ensuite seulement on choisit le mode d’échange, les règles de reprise, le niveau de supervision et les responsabilités métier.
Décision 1
Des commandes et factures qui ne se doublonnent pas lors des retries.
Décision 2
Des stocks diffusables mieux alignés entre Odoo, boutique, WMS et marketplaces.
Décision 3
Des erreurs Odoo lisibles par les équipes, avec des reprises ciblées.
Décision 4
Une architecture prête à absorber plusieurs canaux sans empiler des scripts isolés.
Premier lot
Cadrer le premier flux Odoo ERP avant de développer le connecteur.
On qualifie la source de vérité, les objets, les droits, les volumes, les erreurs et la reprise attendue. Vous obtenez un premier lot décidable, proportionné au risque métier et au run réel.
Sorties concrètes
Cartographie source, cible, objets, identifiants et responsabilités.
Vérification des accès, scopes, webhooks, quotas et contraintes fournisseur.
Choix du pattern : connecteur direct, middleware, file, batch ou API métier.
Critères de recette, logs, alertes, reprise et documentation attendue.
Preuves d’intégration
Trois flux pour éprouver le contrat, la reprise et le run.
Chaque scénario part d’un usage propre à cet univers API et le relie à une entrée contrôlée, un livrable exploitable et une décision de production.
Preuve directe
- Scénario terrain
- Dawap a livré des flux Odoo autour des comptes, catalogues, prix, commandes, stocks, livraisons et documents sur une chaîne B2B en production.
- Architecture
- Import e-commerce ou marketplace, acceptation, lignes, taxes, frais, statuts, tracking et rapprochement avec les documents Odoo.
- Livrable
- Cartographie des modules Odoo, objets API, droits, sources de vérité, version cible et dépendances SI.
- Décision
- Passer en production, corriger le contrat ou arrêter le flux avant qu’il ne fragilise le run.
- Résultat vérifiable
- Des commandes et factures qui ne se doublonnent pas lors des retries.
Références proches
- Scénario terrain
- Les projets ERP, e-commerce, marketplace et logistique montrent la même exigence : mapping fiable, reprises, statuts, supervision et run exploitable.
- Architecture
- Stock disponible, réservations, multi-entrepôts, mouvements, ruptures, buffers canal et synchronisation des quantités diffusables.
- Livrable
- Middleware Odoo JSON-2, RPC legacy ou couche dédiée avec mappings, validations et règles métier.
- Décision
- Passer en production, corriger le contrat ou arrêter le flux avant qu’il ne fragilise le run.
- Résultat vérifiable
- Des stocks diffusables mieux alignés entre Odoo, boutique, WMS et marketplaces.
Approche
- Scénario terrain
- Sur un nouveau périmètre Odoo, on commence par les modules, objets, droits, sources de vérité et scénarios d’erreur avant de coder le connecteur.
- Architecture
- Création de factures, avoirs, paiements, statuts comptables, pièces justificatives et cohérence avec les règles de gestion.
- Livrable
- Gestion des files, retries, idempotence, logs corrélés, replay et quarantaine des erreurs.
- Décision
- Passer en production, corriger le contrat ou arrêter le flux avant qu’il ne fragilise le run.
- Résultat vérifiable
- Des erreurs Odoo lisibles par les équipes, avec des reprises ciblées.
Maillage ERP
Poursuivre dans le bon périmètre API
Odoo touche souvent plusieurs familles de flux. Ces pages permettent de repartir vers le bon niveau de cadrage si le besoin dépasse le seul ERP.
Avis & exigence projet
Des intégrations Odoo jugées sur la fiabilité du run ERP.
Les objets Odoo, sources de vérité, mappings et responsabilités sont posés avant de développer.
Les erreurs, doublons, statuts bloqués et écarts de stock peuvent être isolés puis rejoués.
Commerce, finance, logistique et DSI gardent une lecture commune des flux critiques.
Questions d’achat
Questions fréquentes sur l’intégration Odoo API
Les réponses utiles avant de connecter Odoo au reste du SI : API disponibles, modules spécifiques, écritures sensibles, doublons, multi-sociétés et run.
01Quelle API Odoo utilisez-vous pour une intégration ERP ?
Nous cadrons d’abord la version Odoo et la trajectoire cible. Odoo 19 introduit JSON-2 et déprécie les endpoints XML-RPC/JSON-RPC, dont le retrait est annoncé pour Odoo 22 et Odoo Online 21.1. Un projet neuf prépare donc JSON-2 ou une couche dédiée ; un existant migre progressivement selon ses modules, droits et risques.
02Faut-il migrer une intégration Odoo XML-RPC existante ?
Oui si elle porte des flux critiques ou si une montée de version est prévue. La bonne approche consiste à inventorier les appels `execute_kw`, les modèles réellement utilisés, les scripts cron, les modules personnalisés et les reprises, puis à migrer par objet métier plutôt que par simple remplacement technique.
03Pouvez-vous connecter Odoo à un site e-commerce ?
Oui. Nous pouvons connecter Odoo à Shopify, PrestaShop, Magento, WooCommerce, Sylius, VTEX ou une boutique sur mesure pour synchroniser commandes, clients, produits, stocks, factures, paiements, retours et statuts.
04Comment évitez-vous les doublons de commandes ou de factures ?
Nous ne supposons pas qu’un nouvel appel est sans effet. Le middleware conserve une clé métier, relit les objets Odoo et l’aval après une réponse ambiguë, puis bloque toute seconde écriture tant que commande, picking ou facture existants ne sont pas expliqués.
05Comment gérez-vous les modules Odoo personnalisés ?
Nous auditons champs, modèles, méthodes, dépendances, droits d’accès, règles d’enregistrement et sociétés avant développement. L’intégration utilise un compte et une clé dédiés, puis une allowlist côté middleware ; si nécessaire, une couche API évite de coupler les autres outils aux comportements internes du module.
06Odoo ERP ou Odoo CRM : quelle intégration choisir ?
Odoo ERP porte notamment commandes, produits, stocks, factures et achats ; Odoo CRM porte leads, opportunités et activités. En multi-sociétés ou multi-entrepôts, nous séparons aussi sociétés, dépôts, fiscalités, journaux et droits afin que chaque flux reste rattaché au bon périmètre.
Intégration API Odoo sur mesure
Votre intégration Odoo doit tenir en production ?
En 15 minutes, on peut qualifier votre version Odoo, vos modules, les flux critiques, les incidents actuels et le premier lot réaliste pour fiabiliser commandes, stocks, factures ou synchronisations métier.
Cadrer mon premier flux Odoo