Solucionar problemas em contas de vendedores

Saiba como solucionar e resolver erros de API em contas de vendedores.

Este tópico descreve como solucionar problemas em uma conta de vendedor quando você encontra um erro de API. Usar os métodos de solução de problemas a seguir pode ajudar a rastrear erros e levar à transmissão bem-sucedida de uma chamada de API entre a SP-API e o Seller Central.

As APIs do parceiro de vendas fornecem mensagens de erro que ajudam você a rastrear erros. Tanto os problemas da conta quanto as chamadas incorretas da API podem causar um erro. No exemplo a seguir, o 400 resposta de erro do createFeed a operação foi causada por um problema de conta inativa.

{ "errors": [ { "code": "InvalidInput", "message": "Invalid request parameters", "details": "" } ] }
Código de erroCausaEtapas para resolver
400

A resposta do createFeed a operação foi causada por um problema de conta inativa.

O vendedor deve verificar o status da conta nesse mercado. Observe que o createFeedDocument a operação não retorna um erro até que o vendedor ligue para o createFeed operação.

Solução de problemas de um erro de API

Ao receber uma mensagem de erro da API, você deve determinar se ela foi causada por um problema na conta. Verifique as seguintes condições:

  • Há algum problema com a solicitação em si?
  • Todos os vendedores estão tendo o mesmo problema?
  • O vendedor está ativo no mercado designado?

O fluxograma a seguir pode ajudar você a determinar a estratégia mais adequada.

Fluxograma de solução de problemas de erros na

Determinar a causa de um erro de API

Quando você recebe um erro de API e a mensagem de erro não contém informações suficientes para ajudar a detectar o problema imediatamente, é necessário primeiro verificar o código de status HTTP. Um código de status de 200 significa que a chamada da API foi bem-sucedida. Se o código de status for uma classe 400 ou 500, a chamada da API falhou.

Como exemplo, a API getOrders retorna uma classe 200, mas a resposta é uma lista vazia. Nesse caso, a chamada da API foi bem-sucedida.

Para obter a resposta correta da API, verifique os parâmetros de solicitação relevantes. Por exemplo, verifique se o intervalo de datas especificado no parâmetro de consulta não deve ter pedidos.

O 500 A classe revela um erro interno do servidor indicando que o servidor Amazon não atendeu a uma solicitação. No entanto, para algumas APIs específicas, como a getListingOffersBatch operação, se o parâmetro de URI errado estiver presente no corpo da solicitação, a resposta será 500 em vez de 400.

Os documentos técnicos a seguir abrangem estratégias de solução de problemas e otimização relacionadas a 429 e 403 Códigos de status HTTP:

Se você ainda tiver um problema, verifique suas funções e tokens.

Etapa 1: Verificar funções e tokens

Depois de confirmar o erro, se o código de erro e as mensagens não fornecerem soluções, consulte a equipe de engenharia para determinar se alguma alteração recente no código pode ter causado uma falha na chamada de API. Verifique os parâmetros da função e do token, especialmente ao usar uma nova API.

Roles

Ao verificar os parâmetros da função, certifique-se de que um aplicativo tenha a papel correto para a chamada de API. Por exemplo, alguns relatórios analíticos para proprietários de marcas (como o GET_BRAND_ANALYTICS_ALTERNATE_PURCHASE_REPORT o relatório, que está disponível nas regiões NA, UE e FE) exige o Função de análise de marca. Além disso, certifique-se de que a função seja aplicada tanto ao perfil do desenvolvedor quanto ao aplicativo, ou a um 403 pode ocorrer um erro.

Tokens de acesso

Em seguida, verifique os tokens de acesso. Existem três tipos principais de tokens de acesso baseados no tipo de solicitação de API.

  • O token de acesso

O token de acesso é o token de acesso mais comumente usado para chamadas de SP-API. Se você incluir a chave refreshToken no parâmetro de consulta da operação LWA, então o token de acesso aparecerá na resposta.

  • Token de acesso para operações sem concessão

O token de acesso para operações Grantless é usado somente para grantless operations.

Certifique-se de incluir o parâmetro scope no parâmetro de consulta da LWA operation, especificando SCOPE_NOTIFICATIONS_API para a API Notifications ou SCOPE_MIGRATION_API para a API Authorization.

  • Token de dados restritos

Um token de dados restritos (RDT) é usado somente para obter dados de informações de identificação pessoal (PII), como endereço de entrega, nome do comprador ou informações tributárias.

Um RDT só pode ser obtido por meio da API Tokens. Por exemplo, se um Desenvolvedor precisar buscar informações de endereço de entrega na resposta da API getOrders, o Desenvolvedor deve primeiro usar o token de acesso para solicitar um RDT por meio da API Tokens e, em seguida, usar o RDT da resposta como token de acesso para chamar a API getOrders.

Ao adotar uma nova API, a melhor prática é usar o Postman e começar com uma simples chamada de API com os parâmetros mínimos. Quando possível, use somente os parâmetros necessários. Verifique se a chamada da API foi bem-sucedida e, em seguida, adicione as opções uma a uma para evitar parâmetros opcionais conflitantes.

Depois de verificar as funções e os tokens, verifique os caminhos.

Etapa 2: Verificar caminhos

A verificação de caminhos permite distinguir se um erro se origina de problemas na conta do vendedor.

Para determinar se os vendedores estão recebendo o mesmo erro, recomendamos registrar constantemente o seguinte para cada solicitação HTTP.

  • Caminho do recurso
  • Código de status
  • Mensagem de erro
  • ID do vendedor (ID do comerciante)
  • ID do marketplace

Ao registrar essas informações, você está criando registros que podem ser revisados a qualquer momento para ajudá-lo a identificar problemas com sua conta. Essas informações do mercado são usadas em Etapa 3.

Quando ocorrer um erro, verifique o caminho do recurso da API para identificar a operação da API e, em seguida, filtre o registro desse caminho do recurso para determinar quantos vendedores têm um status de erro.

Se um serviço estiver com problemas de back-end, o erro retornará para todos os vendedores. A mensagem de erro é indicativa de um problema na conta se apenas um vendedor, ou um grupo limitado de vendedores, o encontrar. Se apenas alguns vendedores receberem uma mensagem de erro, você precisará fazer mais depurações para encontrar o problema. Ao comparar o número de ocorrências do mesmo erro, você pode determinar aproximadamente se a próxima etapa de solução de problemas é continuar com Etapa 3 ou para entrar em contato com os vendedores.

Etapa 3: Determinar o mercado afetado

A etapa final é verificar quais mercado o vendedor participa da conta que está causando o erro.

As falhas nas chamadas de API podem ocorrer quando os vendedores fornecem informações incorretas da conta. Para evitar isso, use o getMarketplaceParticipations operação para determinar em quais mercados um vendedor está participando.

Se você receber alguma das respostas a seguir, verifique novamente com o vendedor sobre a conta dele nesse mercado ou peça que ele autorize novamente:

  • 403 + Unauthorized.
  • O mercado esperado não está incluído na resposta.
  • O valor do isParticipating campo neste mercado é false.

Exemplo de resposta para a região do Extremo 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 } } ] }

Também é necessário verificar se a API está disponível para o mercado, especialmente para operações de API de relatórios, API de feeds e API de notificações, porque nem todos os caminhos de recursos estão disponíveis para todos os mercados.

Para determinar qual mercado é compatível com uma API, consulte a documentação sobre tipos de feeds, tipos de relatórios e tipo de notificação.

Uma forma de ajudar a evitar problemas na conta é configurar APIs para ajudar você a monitorar a conta.

Usar APIs para evitar problemas na conta

Saber se um vendedor tem um problema na conta antes de fazer a chamada de API é útil para evitar erros desnecessários de API. Há duas APIs que você pode solicitar para monitorar o status de uma conta.

  • API de tipo de notificação ACCOUNT_STATUS_CHANGED
    Uma notificação é enviada sempre que o status da conta muda para pares vendedor/mercado. Ao implementar esse tipo de notificação, os Desenvolvedores receberão uma notificação sempre que o status da conta do comerciante mudar entre NORMAL, AT_RISK ou DEACTIVATED. Acesse as Informações da conta do vendedor no Seller Central se receber a notificação de que currentAccountStatus não é NORMAL.

  • GET_V2_SELLER_PERFORMANCE_REPORT Relatório
    Esse tipo de relatório contém dados de métricas de desempenho individuais do painel de integridade da conta do Seller Central. Fornecemos uma resposta semelhante ao exemplo a seguir. No entanto, você não deve confiar nesse 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" } ] }

Chame periodicamente a GET_V2_SELLER_PERFORMANCE_REPORT e verifique o primeiro nível do objeto performanceMetrics. Ele inclui métricas da conta e cada métrica contém informações de status.

Se alguma métrica não estiver com o status GOOD, verifique o status da conta do vendedor no Seller Central para obter mais informações. Confira o Guia do usuário da API de relatórios para obter mais informações sobre a adoção dessa API.

Ao combinar o uso das APIs ACCOUNT_STATUS_CHANGED e GET_V2_SELLER_PERFORMANCE_REPORT com a Sellers API, você pode determinar em quais mercados o vendedor participou, se a conta está ativa nesse mercado e se há algum indício de desempenho ruim da conta.

O fluxograma a seguir descreve as práticas recomendadas para o design do sistema em relação à prevenção de problemas na conta.

Fluxograma de prevenção de problemas na conta


Esta página ajudou você?