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:
You can get more information about how to use this module and its business logic at VTEX Help.
GET
: routes are not rate limited at the momentPUT or POST
: 40 requests/second/account
in any price insert/update route with 1000 Burst CreditsDELETE
: 16 requests/second/account
in any price deletion route, with 300 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
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 routeRatelimit-Remaining
- How many Burst Credits are still available to useRatelimit-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.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.
Use this page to mock Pricing API in your testing and development.
Run our mock API sample using the open source WireMock library, or in the free edition of WireMock Cloud. You'll have a working API server simulating the behavior of Pricing API, which will allow you to keep building and testing even if the actual API you isn't currently available.