Hub per sviluppatoriStato dell'APISupporto

Risoluzione dei problemi relativi agli Account venditore

Scopri come risolvere i problemi e gli errori delle API negli Account venditore.

Questo argomento descrive come risolvere i problemi relativi a un Account venditore quando si verifica un errore API. L'utilizzo dei seguenti metodi di risoluzione dei problemi può aiutare a rintracciare gli errori e portare alla corretta trasmissione di una chiamata API tra SP-API e Seller Central.

Le API di Selling Partner forniscono messaggi di errore che ti aiutano a rintracciare gli errori. Sia i problemi relativi all'account che le chiamate API errate possono causare un errore. Nel seguente esempio, 400 risposta di errore da parte di createFeed l'operazione è stata causata da un problema relativo all'account inattivo.

{ "errors": [ { "code": "InvalidInput", "message": "Invalid request parameters", "details": "" } ] }
Codice di erroreCausaPassaggi per la risoluzione
400

La risposta del createFeed l'operazione è stata causata da un problema relativo all'account inattivo.

Il venditore deve verificare lo stato del proprio account in questo marketplace. Tieni presente che il createFeedDocument l'operazione non restituisce un errore finché il venditore non chiama il createFeed operazione.

Risoluzione di un errore API

Quando ricevi un messaggio di errore API, ti consigliamo di determinare se è stato causato da un problema con l'account. Verifica le seguenti condizioni:

  • C'è un problema con la richiesta stessa?
  • Tutti i venditori hanno lo stesso problema?
  • Il venditore è attivo nel marketplace designato?

Il seguente diagramma di flusso può aiutarti a determinare la linea d'azione più adatta.

Diagramma di flusso per la risoluzione degli errori dell'account

Determinazione della causa di un errore API

Quando ricevi un errore API e il messaggio di errore non contiene informazioni sufficienti per rilevare immediatamente il problema, la prima cosa da controllare è il codice di stato HTTP. Un codice di stato di 200 significa che la chiamata API è andata a buon fine. Se il codice di stato è un 400 o 500 class, la chiamata API non è riuscita.

A titolo di esempio, il getOrders L'API restituisce un 200 classe ma la risposta è una lista vuota. In questo caso, la chiamata API ha avuto successo.

Per recuperare la risposta API corretta, controlla i parametri di richiesta pertinenti. Ad esempio, controlla se si suppone che l'intervallo di date specificato nel parametro di query non contenga ordini.

Le 500 class rivela un errore interno del server che indica che il server Amazon non è riuscito a soddisfare una richiesta. Tuttavia, per alcune API specifiche, come getListingOffersBatch operazione, se nel corpo della richiesta è presente un parametro URI errato, la risposta è 500 invece di 400.

I seguenti documenti tecnici riguardano le strategie di risoluzione dei problemi e ottimizzazione relative a 429 e 403 Codici di stato HTTP:

Se il problema persiste, controlla i ruoli e i token.

Fase 1: Verifica ruoli e token

Dopo aver confermato l'errore, se il codice di errore e i messaggi non forniscono soluzioni, contatta il team di progettazione per determinare se eventuali modifiche recenti al codice potrebbero aver causato un errore di chiamata API. Controlla i parametri del ruolo e del token, soprattutto quando usi una nuova API.

Roles

Quando controllate i parametri del ruolo, assicuratevi che un'applicazione abbia ruolo corretto per la chiamata API. Ad esempio, alcuni report analitici per i proprietari di marchi (come GET_BRAND_ANALYTICS_ALTERNATE_PURCHASE_REPORT rapporto, disponibile nelle regioni NA, UE e FE) richiede Ruolo di Brand Analytics. Inoltre, assicurati che il ruolo sia applicato sia al profilo dello sviluppatore che all'applicazione, oppure a 403 può verificarsi un errore.

Token di accesso

Quindi, controlla i token di accesso. Esistono tre tipi principali di token di accesso basati sul tipo di richiesta API.

  • Il token di accesso

Il token di accesso è il token di accesso più comunemente usato per le chiamate SP-API. Se includi refreshToken chiave nel parametro di interrogazione del LWA operazione, quindi il token di accesso verrà visualizzato nella risposta.

  • Token di accesso per operazioni Grantless

Il token di accesso per le operazioni Grantless viene utilizzato solo per grantless operations.

Assicurati di includere il scope parametro nel parametro di interrogazione del LWA operation, specificando uno dei due SCOPE_NOTIFICATIONS_API per il Notifications API o SCOPE_MIGRATION_API per il Authorization API.

  • Token di dati con restrizioni

Un Restricted Data Token (RDT) viene utilizzato solo per recuperare dati personali identificabili (PII), come l'indirizzo di spedizione, il nome dell'acquirente o informazioni fiscali.

Un RDT può essere recuperato solo tramite Tokens API. Ad esempio, se uno sviluppatore deve recuperare le informazioni sull'indirizzo di spedizione dal getOrders Risposta all'API, lo sviluppatore deve prima utilizzare il token di accesso per richiedere un RDT tramite ilTokens API, quindi utilizza l'RDT della risposta come token di accesso per chiamare il getOrders API.

Quando si adotta una nuova API, la procedura migliore è utilizzare Postman e iniziare con una semplice chiamata API con i parametri minimi. Quando possibile, utilizza solo i parametri richiesti. Assicurati che la chiamata API abbia esito positivo, quindi aggiungi le opzioni una per una per evitare parametri opzionali in conflitto.

Dopo aver controllato i ruoli e i token, controlla i percorsi.

Fase 2: Controlla i percorsi

La verifica dei percorsi ti consente di distinguere se un errore proviene da problemi relativi all'account venditore.

Per determinare se i venditori stanno ricevendo lo stesso errore, consigliamo di registrare costantemente quanto segue per ogni richiesta HTTP.

  • Percorso delle risorse
  • Codice di stato
  • Messaggio di errore
  • ID venditore (ID venditore)
  • ID Marketplace

Registrando queste informazioni, crei record che possono essere esaminati in qualsiasi momento per aiutarti a identificare i problemi con il tuo account. Queste informazioni sul marketplace vengono utilizzate in Fase 3.

Quando si verifica un errore, controlla il percorso delle risorse API per identificare l'operazione dell'API, quindi filtra il registro relativo a questo percorso di risorse per determinare quanti venditori presentano uno stato di errore.

Se un servizio presenta problemi di backend, l'errore si ripresenta per tutti i venditori. Il messaggio di errore è indicativo di un problema relativo all'account se viene riscontrato solo da un venditore o da un gruppo limitato di venditori. Se solo alcuni venditori ricevono un messaggio di errore, dovrai eseguire ulteriori operazioni di debug per individuare il problema. Confrontando il numero di occorrenze dello stesso errore, puoi determinare approssimativamente se il passaggio successivo per la risoluzione del problema è continuare a Fase 3 o per contattare i venditori.

Fase 3: determinazione del marketplace interessato

L'ultimo passo è verificare quale mercato il venditore partecipa, per l'account che ha causato l'errore.

Le chiamate API non riuscite possono essere dovute a venditori che ti hanno fornito informazioni errate sull'account. Per evitare che ciò accada, utilizza il getMarketplaceParticipations operazione per determinare a quali mercati partecipa un venditore.

Se visualizzi una delle seguenti risposte, verifica con il venditore le informazioni relative al suo account in questo marketplace o chiedigli di autorizzarlo nuovamente:

  • 403 + Unauthorized.
  • Il marketplace previsto non è incluso nella risposta.
  • Il valore del isParticipating il campo in questo mercato è false.

Esempio di risposta per la regione dell'Estremo Oriente (FE):

{ "payload": [ { "marketplace": { "id": "A1VC38T7YXB528", "countryCode": "JP", "name": "Amazon.co.jp", "defaultCurrencyCode": "JPY", "defaultLanguageCode": "ja_JP", "domainName": "www.amazon.jp (http://www.amazon.jp/)“ }, "participation": { "isParticipating": true, "hasSuspendedListings": false } }, { "marketplace": { "id": "A1VN0HAN483KP2", "countryCode": "JP", "name": "Non-Amazon", "defaultCurrencyCode": "JPY", "defaultLanguageCode": "ja_JP", "domainName": "jp-shipment-injection.stores.amazon.co.jp" }, "participation": { "isParticipating": true, "hasSuspendedListings": false } } ] }

Dovresti anche verificare se l'API è disponibile per il marketplace, in particolare per API per i report, API dei feed e API di notifica operazioni, perché non tutti i percorsi di risorse sono disponibili per tutti i marketplace.

Per determinare quale marketplace è supportato da un'API, consulta Tipo di feed, Tipo di report e il Tipo di notifica documentazione.

Un modo per prevenire problemi relativi all'account è configurare delle API per aiutarti a monitorare l'account.

Utilizzo delle API per prevenire problemi con l'account

Sapere se un venditore ha un problema con l'account prima di effettuare la chiamata API è utile per prevenire errori API non necessari. Esistono due API che puoi richiedere per monitorare lo stato di un account.

  • ACCOUNT_STATUS_CHANGED API del tipo di notifica
    Viene inviata una notifica ogni volta che lo stato dell'account cambia per le coppie venditore/marketplace. Implementando questo tipo di notifica, gli sviluppatori riceveranno una notifica ogni volta che lo stato dell'account del venditore cambia tra NORMAL, AT_RISK, oppure DEACTIVATED. Accedi alle Informazioni sull'account venditore da Seller Central se ti viene comunicato che currentAccountStatus non è NORMAL.

  • GET_V2_SELLER_PERFORMANCE_REPORT Rapporto
    Questo tipo di rapporto contiene dati sulle metriche delle prestazioni individuali tratti dalla dashboard di Seller Central Account Health. Forniamo una risposta simile all'esempio seguente. Tuttavia, non devi fare affidamento su questo formato.

{ "accountStatuses":[ { "marketplaceId":"A1VC38T7YXB528", "status":"NORMAL" } ], "performanceMetrics":[ { "lateShipmentRate":{}, "invoiceDefectRate":{}, "orderDefectRate":{ "afn":{}, "mfn":{} }, "onTimeDeliveryRate":{}, "validTrackingRate":{}, "preFulfillmentCancellationRate":{}, "warningStates":[], "accountHealthRating":{}, "listingPolicyViolations":{}, "productAuthenticityCustomerComplaints":{}, "productConditionCustomerComplaints":{}, "productSafetyCustomerComplaints":{}, "receivedIntellectualPropertyComplaints":{}, "restrictedProductPolicyViolations":{}, "suspectedIntellectualPropertyViolations":{}, "foodAndProductSafetyIssues":{}, "customerProductReviewsPolicyViolations":{}, "otherPolicyViolations":{}, "documentRequests":{}, "marketplaceId":"A1VC38T7YXB528" } ] }

Chiama periodicamente il GET_V2_SELLER_PERFORMANCE_REPORT e controlla il primo livello del performanceMetrics oggetto. Include le metriche dell'account e ogni metrica contiene informazioni sullo stato.

Se non sono presenti metriche GOOD status, controlla lo stato dell'account del venditore in Seller Central per ulteriori informazioni. Dai un'occhiata al Guida per l'utente dell'API Reports per ulteriori informazioni sull'adozione di questa API.

Combinando l'uso di ACCOUNT_STATUS_CHANGED e GET_V2_SELLER_PERFORMANCE_REPORT API con Sellers API, puoi determinare a quali mercati ha partecipato il venditore, se l'account è attivo in tale marketplace e se vi sono segnali di scarso rendimento dell'account.

Il seguente diagramma di flusso delinea le migliori pratiche per la progettazione del sistema per quanto riguarda la prevenzione dei problemi relativi agli account.

Diagramma di flusso per la prevenzione dei problemi relativi


Questa pagina ti è stata utile?