À partir de la version d’API 2026-07, Shopify rendra accessible dans l’Admin GraphQL API le champ taxSettings de l’objet Customer. Une app autorisée pourra donc lire le tax ID d’un client, par exemple un numéro de TVA, s’il a été collecté et validé au checkout. Pour un marchand, l’intérêt est surtout opérationnel : moins de ressaisie, moins de contrôles manuels, et une donnée plus propre à réinjecter dans le CRM, la facturation ou un ERP.
Checkout et B2B : une donnée client enfin exploitable par les équipes métier
Le vrai sujet n’est pas l’API en elle-même, mais ce qu’elle débloque dans les flux internes. Si votre organisation jongle déjà entre checkout, comptes clients et outils de back-office, cette lecture du tax ID peut éviter des bricolages. Elle permet de synchroniser plus simplement l’identifiant fiscal vers un outil de facturation, un middleware ou un CRM, à condition d’avoir les bons scopes et une architecture déjà prête à consommer cette donnée.
L’intérêt est plus net en B2B. Shopify avait déjà un champ équivalent pour les emplacements d’entreprise via CompanyLocation.taxSettings.taxRegistrationId. Cette évolution rapproche donc les données des clients particuliers et des comptes pros. En clair : plus simple à unifier, mais aussi plus tentant de vouloir brancher ça partout sans avoir clarifié les règles métier.
CRM et facturation : le gain existe, à condition d’avoir un usage précis
Avant d’investir du temps dessus, la question à poser est simple : à quoi va servir ce tax ID chez vous ? Si la réponse est un reporting fiscal, une facturation plus fiable ou un enrichissement CRM, le signal mérite d’être traité. Si c’est juste pour « avoir la donnée », le retour sur effort risque d’être faible.
- read_customers ou read_taxes sont requis pour interroger la donnée.
- Le champ reste en lecture seule : impossible de corriger ou de modifier le tax ID via cette API.
- Le champ peut renvoyer une chaîne ou null, donc il faut gérer les cas incomplets.
- Le sous-champ taxIdValidation n’est pas exposé publiquement.
Le risque : surestimer une lecture API qui ne règle pas la conformité
Cette ouverture ne fait pas disparaître le travail de fond. Elle ne garantit pas la validité fiscale de la donnée, elle ne remplace pas vos contrôles, et elle ne donne pas accès à tout le détail de validation. Si votre process dépend du statut exact du numéro de TVA, il faudra vérifier vos droits d’accès et ne pas supposer que tout est disponible.
Donc, la bonne décision n’est pas de lancer un chantier, mais de demander à vos équipes technique et B2B si ce champ peut réellement supprimer une friction existante. Si oui, branchez-le dans vos flux checkout, CRM ou facturation. Sinon, gardez l’info en veille : c’est utile, mais seulement si vous avez déjà un usage prêt à absorber cette donnée.
