Business Central API devient critique quand l’ERP doit absorber des commandes digitales, exposer des articles, synchroniser des clients, remonter des factures ou alimenter une BI sans perdre la logique comptable. Le piège consiste à traiter Business Central comme une base à écrire, alors que chaque company, item, customer, sales order ou invoice porte des validations métier.
Ce guide sert de support technique. La page intégrateur Microsoft Business Central API reste l’owner business pour les intentions service : middleware ERP, e-commerce, marketplace, portail B2B, reporting, webhooks, extensions et run.
Le bon découpage anti-cannibalisation
Business Central API doit soutenir la landing outil. L’article explique les objets, endpoints et arbitrages. La landing convertit le besoin projet : audit, middleware, reprise de connecteur, flux e-commerce, marketplace, BI ou portail B2B.
Quel owner pour Business Central API
L’intention “Business Central API” cherche rarement une définition. Elle cherche comment brancher l’ERP Microsoft au reste du SI sans casser les règles de vente, stock, facturation ou reporting. L’owner doit donc rester la landing Business Central, avec le blog en soutien pour expliquer les choix techniques.
Le contenu support doit parler aux CTO, DSI, responsables e-commerce, finance et ADV. Il doit montrer ce que l’on peut faire avec les APIs, mais surtout ce qu’il faut refuser : écriture directe sans validation, replay global, webhook non corrélé ou extension AL exposée sans contrat stable.
Sources officielles Microsoft Learn
Microsoft Learn confirme que Business Central API v2.0 sert à créer des Connect apps via REST pour échanger des données entre Business Central et une solution tierce. Les endpoints v2.0 reposent sur les companies et exposent des ressources comme customers, items, sales orders, sales invoices, purchase invoices ou subscriptions selon le périmètre.
Les docs Microsoft indiquent aussi que les APIs doivent être activées selon l’environnement, que le nom d’environnement entre dans l’URI, et que les webhooks passent par des subscriptions sur `/api/v2.0/subscriptions`. Les notifications demandent une logique de handshake, de ressource surveillée et de client state.
Point important pour les extensions : Microsoft précise que l’extension directe des APIs standard avec des champs additionnels n’est pas possible. Si le besoin exige des champs propres, il faut créer une API personnalisée, souvent via une API page en AL, versionnée, webhook-supported et OData v4 enabled.
Sources vérifiées : Business Central API v2.0, endpoints Business Central, webhooks subscriptions et API page type.
Companies, customers, items et sales orders
La première décision consiste à cadrer la company. Un même tenant peut porter plusieurs companies, environnements ou règles de droits. Une intégration qui ne journalise pas company, environnement, application, compte technique et version d’API rend les incidents très difficiles à expliquer.
Les customers et items doivent ensuite être traités comme des référentiels gouvernés. Un client e-commerce ne devient pas automatiquement un customer exploitable en ERP, et un item ne se limite pas à un SKU visible. Les adresses, dimensions, unités, catégories, variantes, prix, taxes et conditions commerciales doivent être validés avant écriture.
Les sales orders portent le risque opérationnel le plus visible. Une commande web ou marketplace doit être normalisée, enrichie, contrôlée puis créée dans Business Central avec une clé de corrélation. Le middleware doit conserver lignes, taxes, remises, transport, paiement, statut, erreurs et décision de replay.
Les invoices et credit memos méritent un seuil plus strict. Quand un document financier existe, la reprise ne doit plus rejouer tout le flux. Elle doit isoler la ligne, corriger la règle, documenter le motif et conserver la preuve que le document final raconte la même histoire que la commande.
API pages, OData et extensions AL
Business Central ne se résume pas aux endpoints standard. Les OData web services, API pages et extensions AL peuvent exposer des données ou comportements spécifiques. C’est puissant, mais cela doit être traité comme un contrat d’intégration, pas comme une porte ouverte vers le modèle interne.
Une API page personnalisée doit préciser publisher, group, version, entity name, entity set name, source table, droits, webhooks attendus, champs exposés et règles de validation. Sans cette fiche, l’intégration devient dépendante d’un détail AL que le support ne saura pas relire.
La bonne pratique consiste à garder une couche middleware stable entre Business Central et les canaux. Le site e-commerce, la marketplace ou la BI n’ont pas besoin de connaître toutes les subtilités AL. Ils ont besoin d’un contrat fiable : créer commande, lire stock, publier statut, récupérer facture, signaler anomalie.
Webhooks, files et reprise ERP
Les webhooks Business Central servent à être notifié lorsqu’une entité change. Ils ne remplacent pas la réconciliation. Un événement peut arriver tard, être rejoué ou ne pas contenir toute la donnée utile au métier. Il doit donc entrer dans une file corrélée avant toute écriture aval.
Une subscription doit garder ressource surveillée, notification URL, clientState, company, environnement, statut, dernière notification et propriétaire. Si la notification concerne un customer, un item ou une invoice, le middleware doit relire l’objet avant de décider une action métier.
Le run doit séparer polling de secours, webhook, batch BI, écriture commande et reprise finance. Une seule file rend le code simple, mais elle peut bloquer un flux critique derrière un enrichissement analytique. Le bon design donne priorité aux commandes et documents financiers, puis aux mises à jour de référentiel, puis au reporting.
Si un événement ne peut pas être rapproché en moins de quinze minutes avec son objet Business Central et sa source externe, il doit passer en quarantaine. La reprise doit être bornée : rejouer une commande, une ligne, un item, une facture ou une notification, jamais tout le lot sans preuve.
Plan d’action Business Central
- Cartographier companies, environnements, comptes techniques, permissions, endpoints v2.0, OData et API pages custom.
- Nommer la source de vérité pour customers, items, sales orders, invoices, inventory, dimensions et statuts.
- Définir les seuils de blocage : client ambigu, item introuvable, commande rejetée, facture déjà engagée, webhook non corrélé.
- Installer les traces : company ID, object ID, external ID, correlation ID, payload réduit, statut normalisé et action de reprise.
- Relier le guide vers la landing Business Central API dès que le besoin devient projet.
Pour prolonger le sujet, le guide API Microsoft Dynamics donne le contexte ERP Microsoft plus large, et le guide réconciliation API aide à traiter les écarts entre source et cible.
