Limites et contraintes

Cette section décrit les limites et les contraintes d'utilisation de l'API Orders

Quotas et limites concernant le nombre de requêtes envoyées

L'API est gratuite, mais elle fait l'objet de quotas et de limites de débit, comme décrit dans l'article Limites publiées pour Content API for Shopping.

Commandes annulées

Les commandes annulées avec le motif noInventory entraînent la suppression du produit de Shopping Actions jusqu'à ce que vous l'ayez mis à jour. Cela n'a pas d'incidence sur vos annonces Shopping.

Commandes test sandbox

Les commandes créées dans l'environnement sandbox à l'aide de orders.createtestorder sont disponibles six mois à compter de leur création. Elles sont ensuite supprimées.

Délais d'expédition des commandes

Actuellement, si une commande n'est pas expédiée dans les 30 jours, Google l'annule automatiquement. Le motif de l'annulation est orderTimeout. Les marchands ne peuvent pas définir cette valeur comme motif d'annulation.

Ordre des opérations de custombatch

L'ordre des opérations de custombatch n'est pas garanti. N'incluez pas dans la même requête par lot des opérations qui dépendent d'une autre opération du même lot.

D'un point de vue conceptuel, supposons que toutes les opérations d'un lot sont exécutées simultanément, et que l'ordre des opérations est non déterministe. Cela signifie généralement que les opérations affectant la même valeur orderID ne doivent pas être placées dans le même lot. Il existe toutefois des exceptions à cette règle.

Fréquence des requêtes

Nous vous recommandons d'attendre d'obtenir une réponse à une requête sur une commande avant d'exécuter une seconde requête. Par exemple, comme la propagation des données de requête dans notre système peut parfois prendre du temps, nous ne garantissons pas qu'une requête GET effectuée tout de suite après une requête POST permettent de vérifier si les modifications ont bien été appliquées. Si la requête POST renvoie une réponse indiquant que l'opération s'est déroulée correctement, cela suffit à prouver que cette requête a été exécutée. Il n'est pas nécessaire d'émettre une requête GET pour le "reconfirmer".

Problème connu

Le sandbox de l'API étant toujours en version d'aperçu, nous avons plusieurs problèmes connus à résoudre. Nous nous efforcerons de tenir à jour cette liste en nous basant sur la dernière version de l'API.

Méthode list

La méthode list présente les problèmes connus suivants :

• maxResults : ce champ n'est pas encore mis en œuvre, mais il sera bientôt disponible. La valeur par défaut sera définie sur 25 résultats, tandis que la valeur maximale autorisée sera de 250.
• orderBy : pour l'instant, le tri par ordre croissant ne fonctionne pas dans ce champ. Il ne permet le tri que par ordre décroissant.
• acknowledged : list peut dépasser le délai en cas d'utilisation du paramètre acknowledged. Pour contourner ce problème, ajoutez placedDateStart à l'appel de méthode, et définissez sa valeur sur "il y a une semaine" ou "il y a un mois" (les commandes remontant à plus d'un mois sont automatiquement annulées).

  Bien que ce problème n'ait pas été observé en production, inclure le paramètre placedDateStart dans l'appel list réduit le temps nécessaire à son exécution.

Attribut actor

Les remboursements, les annulations et les retours comportent un attribut actor que vous pouvez utiliser pour identifier la personne à l'origine de ces différentes actions. Cependant, ce champ n'est pas encore disponible dans les remboursements et les retours de l'objet Orders.

Il le sera ultérieurement.