Sur cette page
Shopify a ajouté ces API dans la version 2026-10. Utilisez-les lorsque votre intégration de gestion des commandes ou de traitement doit prendre connaissance d’une demande d’annulation en attente d’un client avant que le marchand ne la traite.
Limitez les demandes à la suppression d’unités non traitées
La modification prise en charge est la suppression. Dans la version 2026-10, l’entrée lineItems de orderRequestEdit contient uniquement des removals, chacune avec un lineItemId et la quantity demandée. Les quantités partielles sont autorisées. Aucun type de demande n’existe pour les ajouts et les échanges de variantes, ni pour les modifications d’adresse, d’expédition ou de remise.
Dans le parcours natif des comptes clients, les acheteurs sélectionnent Cancel items sur une commande éligible. Les comptes clients classiques ne sont pas pris en charge. Les conditions de configuration de Shopify décrivent l’activation sous Settings > Customer accounts. Utilisez le guide de migration des comptes clients si la boutique utilise encore les comptes classiques.
Lisez Order.requestedEditInformation lorsque vous développez l’interface de l’acheteur. Son objet d’éligibilité expose hasEditableLineItems, editableLineItems et ineligibleLineItems. Affichez les quantités éligibles à partir de cette réponse. Ne supposez pas que chaque unité non traitée est disponible pour une nouvelle demande.
Les demandes natives en libre-service s’appliquent aussi aux commandes B2B. Le traitement d’une demande concernant une commande d’abonnement laisse le contrat d’abonnement actif. L’activation par marché nécessite Advanced ou Plus et l’accès aux paramètres d’actions sur les commandes en accès anticipé dans l’éditeur de paiement et de comptes. Les boutiques qui ne disposent pas de cette option activent les demandes sur tous les marchés.
Configurez l’API et les autorisations
Utilisez les références de la version 2026-10. La ressource de demande est RequestedOrderEdit. Son énumération de statuts contient REQUESTED, RESOLVED et DECLINED. REQUESTED signifie qu’une action du marchand est en attente. Il n’existe aucun état APPROVED.
| Appelant | Opération | Objectif |
|---|---|---|
| Admin API | requestedOrderEditCreate |
Créer une demande au nom d’un acheteur |
| Admin API | requestedOrderEditResolve |
Marquer une demande comme résolue |
| Admin API | requestedOrderEditDecline |
Refuser une demande |
| Customer Account API | orderRequestEdit |
Envoyer la demande de l’acheteur |
| Les deux API | requestedOrderEditCalculate |
Prévisualiser le résultat financier |
Pour les requêtes Admin, demandez read_orders. Les trois mutations Admin nécessitent write_orders et l’autorisation du personnel edit_orders, comme le précise la référence de création. Le processus de modification calculée par le marchand nécessite séparément write_order_edits.
Pour la mutation de l’acheteur, demandez customer_write_pre_authenticated. L’utilisateur doit aussi disposer de l’accès customer_write_orders ou d’un accès préauthentifié à la commande. Pour la requête de prévisualisation de l’acheteur, l’application a besoin de customer_read_pre_authenticated, et l’utilisateur doit disposer de l’accès customer_read_orders ou d’un accès préauthentifié à cette commande précise avant que vous ne proposiez la prévisualisation. La lecture de OrderRequestedEditInformation nécessite customer_read_orders.
Utilisez @idempotent sur orderRequestEdit et réutilisez la clé lorsque vous réessayez le même envoi. Shopify renvoie la demande d’origine au lieu d’en créer une autre.
Mettez le traitement en attente pendant l’examen par le marchand
Aucune mise en attente automatique n’est documentée pour une demande en attente. Le journal des modifications de Shopify décrit la mise en attente du traitement comme une action qu’une application peut effectuer sur les commandes au statut REQUESTED.
Abonnez-vous aux trois sujets de webhook des demandes : requested_order_edit/created, requested_order_edit/resolved et requested_order_edit/declined. Chacun nécessite au moins l’une des autorisations read_orders, read_marketplace_orders ou read_buyer_membership_orders. Les données transmises identifient la commande et les suppressions demandées, avec notamment quantity et resolved_quantity. Les statuts des exemples de webhook sont en minuscules. Les valeurs d’énumération GraphQL sont en majuscules.
Si le marchand souhaite suspendre la préparation pendant l’examen, intégrez cette séquence à votre intégration :
- À la réception de
/created, récupérez la commande et la demande actuelles. Enregistrez l’identifiant de la demande dans les données de la commande de l’entrepôt. - Appliquez la mise en attente du traitement ou le mécanisme d’arrêt de l’entrepôt que votre intégration contrôle. Si l’entrepôt a déjà importé la commande, exigez sa confirmation que la préparation est arrêtée pour les unités demandées.
- À la réception de
/resolvedou de/declined, récupérez les demandes restantes de la commande et les quantités actuelles. Ne levez la mise en attente de votre intégration qu’une fois les demandes en attente et les éventuelles opérations de remboursement nécessaires terminées.
Vérifiez chaque demande. Une commande peut comporter plusieurs demandes, et displayRequestedEditStatus = REQUESTED signifie qu’au moins l’une d’elles nécessite encore une action du marchand. Ne levez pas la mise en attente à la réception d’un seul événement /resolved.
Convenez de la confirmation d’arrêt attendue avant d’activer la libération automatique. Le guide d’intégration de la mise en attente du traitement couvre les contrôles en aval.
Effectuez la suppression avant de clôturer la demande
Dans l’interface d’administration Shopify, filtrez Orders par Customer request. La demande apparaît dans une bannière sur la commande. Les personnes chargées de l’examen doivent disposer de l’autorisation Orders.
Pour une commande payée, Remove items ouvre la page de remboursement avec les articles demandés sélectionnés. Sélectionnez les articles à rembourser, vérifiez le montant et les options de remise en stock, puis cliquez sur Refund. Shopify marque la demande comme résolue. Pour les commandes non payées, Remove items ouvre plutôt la page de remise en stock.
La résolution clôture l’enregistrement de la demande. La référence de requestedOrderEditResolve décrit cette opération comme le fait de marquer la demande comme terminée, et sa seule entrée est l’id de la demande, sans champs de quantité, de remboursement ou de remise en stock. Supprimez et remboursez les unités séparément, et conservez les deux opérations dans le journal d’exécution de votre implémentation.
Utilisez requestedOrderEditCalculate pour prévisualiser le résultat financier de la suppression demandée avant l’envoi. Cette requête renvoie financialSummary et les lignes d’articles calculées. Une prévisualisation n’effectue aucun règlement financier. Notre guide de l’API de modification de commande couvre le processus existant d’ouverture, de préparation et de validation, ainsi que ses opérations de règlement distinctes.
Pour refuser la demande, appelez requestedOrderEditDecline. Son champ facultatif declineNote est un message de notification destiné à l’acheteur, limité à 500 caractères. Dans l’interface d’administration Shopify, Manage request > Mark as resolved clôture en revanche la demande sans modifier la commande ni envoyer d’e-mail au client. Refusez la demande lorsque le marchand refuse la suppression. Ne la marquez comme résolue qu’une fois les unités supprimées et remboursées, ou lorsque la demande a été traitée autrement.
Vérifiez les transitions non documentées avant la mise en production
Dans l’interface d’administration Shopify, le remboursement des articles demandés résout la demande, tout comme l’annulation de la commande, alors que supprimer les articles et reporter leur remboursement laisse la demande ouverte. Shopify ne documente pas si refundCreate ou un orderEditCommit qui supprime les unités demandées résout la demande via l’API. Vérifiez sur une boutique de développement si votre parcours API se comporte comme l’interface d’administration avant de vous y fier.
Créez une demande pour une partie d’une ligne non traitée, puis traitez cette quantité via le parcours de remboursement ou de modification prévu, sans appeler requestedOrderEditResolve. Inspectez le statut de la demande et resolvedQuantity obtenus, ainsi que les unités restantes de la commande et la transaction de remboursement. Consignez les webhooks de demande reçus.
Créez une autre demande portant sur d’autres unités éligibles de la même commande, puis testez votre gestionnaire de libération pendant qu’une demande reste en attente. Maintenez le blocage de l’entrepôt tant que le marchand a encore une demande à examiner. Si la suppression ou le remboursement échoue, affichez une exception visible pour le marchand et maintenez la commande bloquée.
Pour la reprise après incident, exécutez une requête orders paginée avec le filtre requested_order_edit_status:requested. Récupérez la connexion requestedOrderEdits de chaque commande correspondante et rapprochez-la de vos enregistrements de demandes. Rapprochez aussi, par identifiant, les commandes que votre intégration maintient en attente, car une commande dont la dernière demande a été clôturée pendant qu’un webhook a été manqué ne figure plus dans cette recherche. Définissez l’intervalle de vérification en fonction des règles de libération de l’entrepôt.
Choisissez qui effectue la modification
Orientez les ajouts vers un autre parcours que l’API de demande de l’acheteur. Le parcours de modification par le marchand de Shopify permet d’ajouter des produits avant le traitement.
Pour les clients qui ont besoin d’échanger des variantes, de corriger une adresse ou d’ajouter des articles pendant une période de modification définie par le marchand, les boutiques utilisent une application de modification en libre-service comme Revize. Son paramètre Hold orders, sous Fulfillment while editing, met le traitement en attente tant que le délai de modification à durée définie n’est pas écoulé, puis le libère selon le moment de libération et les conditions de paiement configurés. Avec l’échéance Until fulfillment, Revize n’applique aucune mise en attente.
| Modification demandée par l’acheteur | Modification par le marchand | Revize (application en libre-service) | |
|---|---|---|---|
| Qui la lance | L’acheteur dans les comptes clients ou via orderRequestEdit. Une application peut créer une demande pour l’acheteur |
Le personnel du marchand ou une application utilisant l’API de modification de commande | L’acheteur sur la page de statut de commande de Shopify |
| Qui l’approuve | Le marchand ou l’application examine et traite ou refuse la demande | Le personnel ou l’application effectue la modification | Le marchand définit les actions autorisées à l’avance. L’annulation éligible est automatique |
| Ce qui peut changer | Suppression d’unités non traitées, y compris des quantités partielles. L’envoi ne modifie rien | Produits, quantités, frais d’expédition, remises manuelles dans les limites de modification natives | Modifications de variante et de quantité, adresse de livraison, produits ajoutés. L’ajout de produits nécessite Pro |
| Paiement | La création et la résolution ne déclenchent aucun remboursement. Le traitement de la suppression nécessite une décision de remboursement | Une hausse du total permet l’envoi d’une facture mise à jour. Une baisse du total permet un remboursement | Pay now, Refund ou Confirm, selon que le total augmente, diminue ou reste identique. Shopify effectue le paiement ou le remboursement ; Pay now encaisse uniquement la différence |
| Traitement | Unités non traitées uniquement. Aucune mise en attente automatique documentée | Modifications de quantité et suppressions : uniquement pour les lignes d’articles non traitées. Les remises manuelles peuvent aussi être modifiées sur les articles déjà traités | Avant le traitement, pendant la période définie par le marchand. Le mode Hold orders met le traitement en attente |
Configurez Fulfillment while editing avec l’entrepôt avant d’ouvrir le parcours de modification pour les clients. Pour les instructions d’annulation destinées aux acheteurs, orientez les clients vers le guide d’annulation.
Questions fréquentes
Notre demande est RESOLVED, mais les unités sont toujours présentes. L’API a-t-elle échoué ?
Le statut seul ne prouve pas la suppression. requestedOrderEditResolve marque la demande comme terminée et prend uniquement l’id de la demande, sans champs de quantité, de remboursement ou de remise en stock. L’équipe d’assistance doit inspecter la commande réelle et l’enregistrement du remboursement avant d’indiquer à l’acheteur que le traitement est terminé.
L’acheteur peut-il demander un échange de taille via ces API ?
Non. Les entrées de demande de la version 2026-10 prennent uniquement en charge les suppressions d’unités non traitées. Orientez le changement de taille vers le processus de modification par le marchand ou de modification en libre-service pour les clients de la boutique.
Un webhook de résolution signifie-t-il que toutes les demandes de cette commande sont clôturées ?
Non. Récupérez requestedOrderEdits ou inspectez displayRequestedEditStatus avant de libérer la commande dans l’entrepôt. Une valeur REQUESTED au niveau de la commande signifie qu’une action du marchand reste en attente sur au moins une demande.
Devons-nous conserver nos abonnements aux demandes d’annulation d’ordres de traitement ?
Conservez-les si votre intégration de service de traitement en a besoin. Les sujets fulfillment_orders/cancellation_request_* concernent les demandes d’un marchand ou d’une application adressées à un service de traitement. Les modifications demandées par l’acheteur utilisent requested_order_edit/* et nécessitent leur propre gestion.