Connecter Brightpearl : recevoir les commandes, consulter le stock

Obtenez d’abord app_ref et dev_ref depuis votre application dans le portail développeur Brightpearl, puis lancez l’autorisation OAuth de votre compte pour obtenir l’access token et l’api_domain pour datacenter, saisissez les cinq champs dans Integration, testez, mappez, activez : les commandes de vente arrivent et le stock peut être consulté.

Le connecteur Brightpearl importe les commandes de vente de Brightpearl dans ce système et peut consulter la disponibilité du stock des produits détenue dans Brightpearl. Il lit les données de Brightpearl : il n’importe pas les clients de Brightpearl et ne renvoie ni le stock ni aucun autre changement vers Brightpearl. L’ordre compte ici : la valeur de datacenter ne se choisit pas dans une liste, elle est renvoyée comme api_domain dans la réponse du token OAuth, vous terminez donc l’autorisation d’abord et vous remplissez la connexion ensuite.

Prérequis#

• Un compte Brightpearl, et son code de compte : la partie sous-domaine de votre adresse Brightpearl. Par exemple, dans acme.brightpearl.com, le code de compte est acme.
• Accès au portail développeur Brightpearl sur developer.brightpearl.com, et une application pour cette intégration : il vous faut sa référence d’application et votre référence de développeur.
• Vous pouvez terminer le flux OAuth2 Authorization Code pour ce compte Brightpearl, depuis l’adresse d’autorisation indiquée à l’étape des identifiants.
• Vous comprenez l’ordre inversé pour datacenter : il vient de la réponse du token, comme api_domain, après l’autorisation. Ne le devinez pas et n’y saisissez pas le sous-domaine du compte.

Obtenir les identifiants#

1. Notez d’abord votre code de compte : la partie sous-domaine de votre adresse Brightpearl, par ex. acme dans acme.brightpearl.com.
2. Ouvrez le portail développeur Brightpearl sur developer.brightpearl.com, ouvrez votre application et notez sa référence d’application. C’est la valeur de app_ref, et cette même référence d’application sert aussi de client_id dans le flux OAuth.
3. Notez en même temps votre référence de développeur. C’est la valeur de dev_ref : elle est envoyée avec chaque requête comme en-tête brightpearl-dev-ref, tout comme app_ref est envoyé comme brightpearl-app-ref.
4. Lancez l’autorisation OAuth de votre compte depuis https://oauth.brightpearl.com/authorize/{account}, avec votre propre code de compte à la place de {account}, et terminez le flux Authorization Code Grant pour obtenir l’access token.
5. Dans cette même réponse du token, notez deux valeurs : l’access_token lui-même, et la valeur api_domain. L’api_domain, par ex. use1.brightpearlconnect.com, est exactement ce qui va dans le champ datacenter : copiez-le depuis la réponse, ne le construisez pas vous-même.

Remplir dans Integration#

1. Ouvrez Integration → Marketplace → Brightpearl → Nouvelle connexion. Les cinq champs ci-dessous sont tous obligatoires.
2. account, obligatoire, code de compte Brightpearl : la partie sous-domaine de votre adresse Brightpearl, par ex. acme.
3. datacenter, obligatoire, domaine du datacenter de l’API : saisissez l’api_domain renvoyé dans la réponse du token OAuth, par ex. use1.brightpearlconnect.com. Ne saisissez pas ici le sous-domaine du compte.
4. app_ref, obligatoire, référence d’application : la référence d’application de votre application dans le portail développeur Brightpearl, sur developer.brightpearl.com.
5. dev_ref, obligatoire, référence de développeur : votre référence de développeur Brightpearl. Elle est envoyée comme en-tête brightpearl-dev-ref à chaque requête.
6. access_token, obligatoire, token d’accès OAuth2 : collez l’access token obtenu du flux Authorization Code Grant. C’est un champ de type mot de passe, conservé comme secret.

Tester la connexion#

Cliquez sur Tester la connexion. Le test vérifie d’abord les cinq champs — account, datacenter, app_ref, dev_ref et access_token — et, si l’un manque, il s’arrête et signale le champ manquant avant d’envoyer la moindre requête. Sinon, il envoie une requête avec trois en-têtes, Authorization: Bearer avec votre token, brightpearl-dev-ref et brightpearl-app-ref, pour lire les données de référence des statuts de commande : GET https://{datacenter}/public-api/{account}/order-service/order-status, avec vos propres valeurs de datacenter et d’account dans l’adresse. C’est la vérification en lecture seule la plus légère de Brightpearl. Une réponse 200 signifie que la connexion fonctionne. Une réponse 401 renvoie au token. Une réponse 403 renvoie à la permission. Le test expire après 12 secondes.

Mapping / choisir un modèle#

Choisissez le mapping standard Brightpearl. Les commandes de vente sont trouvées via la recherche du service de commandes de Brightpearl puis lues en entier, et les consultations de stock lisent la disponibilité des produits depuis le service d’entrepôt. Après un test réussi, lancez une extraction et comparez une commande réelle côte à côte (numéro de commande, nom du client affiché sur la commande, lignes et quantités), puis comparez la disponibilité d’un produit avec ce qu’affiche Brightpearl, avant d’activer. Si un champ de vos commandes diffère, ajustez ce champ dans le mapping plutôt que de modifier les enregistrements dans Brightpearl.

Activer#

Après activation, la connexion importe les commandes de vente de Brightpearl dans ce système selon la fréquence définie, et les consultations de stock lisent la disponibilité actuelle des produits dans Brightpearl. Surveillez les premières extractions dans Runs / Logs et comparez-les avec Brightpearl avant de laisser la connexion sans surveillance. Quand l’access token cesse de fonctionner, relancez l’autorisation OAuth pour le même compte, puis mettez à jour ensemble access_token et datacenter depuis la nouvelle réponse du token.

Ce que cette connexion ne fait pas : elle n’importe pas les clients de Brightpearl et ne renvoie ni le stock, ni le statut des commandes, ni les résultats de fulfillment vers Brightpearl. Continuez à gérer cela dans Brightpearl même, ou dans les systèmes où le travail se fait réellement.

FAQ#

Le test échoue avec 401 — le problème vient du token

Brightpearl n’a pas accepté l’access token envoyé avec le test. Le token du champ access_token est incorrect, incomplet, ou n’a pas été obtenu pour ce compte via le flux Authorization Code Grant : le test lit les données de référence des statuts de commande comme vérification du token Bearer, et un token que Brightpearl ne peut pas accepter échoue là en premier.

Relancez l’autorisation depuis https://oauth.brightpearl.com/authorize/{account} avec votre propre code de compte, terminez le flux Authorization Code Grant, collez le nouvel access token en entier, et recopiez datacenter depuis cette même réponse du token comme api_domain. Enregistrez, puis retestez.

Le test échoue avec 403 — un problème de permission

C’est différent du 401 : le token a été accepté, mais l’application ou le compte derrière lui n’est pas autorisé à lire les données de référence des statuts de commande utilisées par le test. Relancer l’autorisation avec la même application et le même accès continuera de renvoyer 403.

Vérifiez dans Brightpearl ce à quoi l’application identifiée par app_ref peut accéder pour ce compte, et vérifiez que dev_ref et app_ref sont bien la paire utilisée avec le token. Donnez à l’application l’accès en lecture dont la connexion a besoin, ou utilisez une application qui l’a déjà, puis autorisez à nouveau, mettez à jour les champs depuis la nouvelle réponse du token, et retestez.

Le test s’arrête avant d’envoyer une requête et signale un champ manquant

L’un des cinq champs obligatoires — account, datacenter, app_ref, dev_ref ou access_token — est vide. Le test vérifie les cinq d’abord, car l’adresse de la requête a besoin d’account et de datacenter, et les en-têtes ont besoin d’app_ref, de dev_ref et du token.

Remplissez le champ manquant depuis sa propre source : account depuis votre adresse Brightpearl, app_ref et dev_ref depuis le portail développeur, et access_token plus datacenter depuis la réponse du token OAuth. Enregistrez, puis retestez.

J’ai saisi le sous-domaine du compte comme datacenter et le test échoue

account et datacenter sont deux valeurs différentes, de formes différentes. account est le sous-domaine de votre adresse Brightpearl, par ex. acme. datacenter est l’api_domain renvoyé dans la réponse du token OAuth, sous la forme use1.brightpearlconnect.com. Avec la valeur d’account dans le champ datacenter, la requête de test part vers la mauvaise adresse.

Revenez à la réponse du token de votre autorisation OAuth, copiez la valeur api_domain exactement dans le champ datacenter, laissez account comme le seul sous-domaine, enregistrez, puis retestez.

Connecté, mais aucune commande de vente n’est importée

La connexion fonctionne — le test a lu les données de référence des statuts de commande avec succès — mais il n’y a rien de nouveau à importer : Brightpearl n’a pas de nouvelles commandes de vente dans la plage d’extraction pour ce compte, ou ces commandes sont sous un compte différent du code de compte de la connexion.

Créez ou confirmez une commande de vente dans Brightpearl sous le même code de compte que la connexion, lancez une extraction manuelle et confirmez que la commande apparaît dans l’aperçu ou dans Runs / Logs.

La consultation de stock ne renvoie aucune disponibilité pour un produit

La connexion peut lire la disponibilité des produits dans Brightpearl, mais ce produit n’a aucun enregistrement de disponibilité correspondant à lire, ou le code produit du mapping ne correspond pas au produit dans Brightpearl. Le test peut réussir alors qu’un produit donné n’a toujours rien à renvoyer.

Vérifiez d’abord le produit et sa disponibilité dans Brightpearl, puis vérifiez le code produit de cet article dans le mapping et corrigez-le pour qu’il corresponde à Brightpearl. Relancez la consultation de stock pour ce seul produit.