API Pricing API
Consulte Pricing API, do provedor vtex.local, versão 1.0: documentação, especificação OpenAPI 3.0.0 e referências para planejar a integração.
vtex.local · Versão 1.0
Conheça a plataforma
O que integrar com Pricing API
Descrição técnica preservada da especificação de origem. A versão do contrato ajuda a identificar a API; confirme a disponibilidade atual no fornecedor.
> Check the new Pricing onboarding guide. We created this guide to improve the onboarding experience for developers at VTEX. It assembles all documentation on our Developer Portal about Pricing and is organized by focusing on the developer's journey. Pricing is the VTEX module responsible for the SKU's price list. At this module we have the base price of each SKU, some optional fixed prices by trade policy, and some rules that can be applied to generate dynamically different final prices according to the purchase context and the trade policy. The variables used in this collection are: * {{accountName}} = You VTEX account name. * {{tradePolicyId}} = Current Trade Policy ID. * {{itemId}} = SKU ID. * {{X-VTEX-API-AppKey}} and {{X-VTEX-API-AppToken}} = Credentials. You can get more information about how to use this module and its business logic at VTEX Help. Rate Limits Limits per route - GET: routes are not rate limited at the moment - PUT or POST: 40 requests/second/account in any price insert/update route with 1000 *Burst Credits* - DELETE: 16 requests/second/account in any price deletion route, with 300 *Burst Credits*. What are Burst Credits? In case the account exceeds the limit frequency for a Rate Limiter (for instance, when one account makes 41 requests/second in any price insert/update route), we decrease from the *Burst Credit* count the exceeding (in this example, *1 Credit*). In the event of the *Burst Credits* reaching 0 (zero), the request is blocked with a Status 429 response. The credits fill up over time when the route is not being used, in the same rate as the route's Rate Limiter. In our example, for each second not sending a PUT or POST request, we increase *40 Burst Credits* to this Rate Limiter New Response Headers In the response headers of any request to Pricing v2 there are some new headers indicating the current status of the Rate Limiting. This information may be useful to evaluate the ideal frequency to send requests to a route, and when to send a new request in the event of reaching a Rate Limit. - Ratelimit-Limit - Total *Burst Credits* offered to a route - Ratelimit-Remaining - How many *Burst Credits* are still available to use - Ratelimit-Reset - How long (in seconds) it will take to the *Burst Credits* to fill up completely (It will fill up to the Ratelimit-Limit) - Retry-After - Indicates how many seconds you will need to wait until the Rate Limiter accepts a new request to this route again. If this header response exists, this means your current request has been rate limited and has not been processed. How to integrate with Pricing v2 considering our Rate Limits Integrate considering the limits of requests/route/account specified in the *Limits per route* section, avoiding to surpass this frequency. If you happen to be Rate Limited, wait the time in seconds specified in Retry-After before making another request to the service, and reduce the rate of requests per second that your integration is making.
Ficha técnica
Como funciona a integração
Versões, permissões, preços e limites podem mudar. Consulte a documentação da plataforma antes de implementar.
Do planejamento à produção
Checklist para integrar Pricing API
- Defina o fluxo. Identifique quais dados precisam circular, o sistema de origem e o resultado esperado.
- Leia os requisitos oficiais. Verifique acesso à API, plano necessário, versão e ambiente de testes.
- Configure o acesso com segurança. Guarde credenciais secretas no servidor e conceda apenas as permissões necessárias. Restrinja chaves públicas conforme a documentação do fornecedor.
- Teste a primeira requisição. Valide os campos, a paginação e o formato de resposta com dados de teste.
- Prepare o tratamento de falhas. Considere limites de requisição, retentativas com espera e prevenção de operações duplicadas.
- Acompanhe a integração. Registre erros sem expor dados sensíveis e monitore alterações na API.