Shopwaive API rate limits
Find Shopwaive's general API rate limit protocol below
To ensure our platform remains stable and fair for everyone, some Shopwaive APIs are rate-limited. We use a variety of strategies to enforce rate limits. We ask developers to use industry standard techniques for limiting calls, caching results, and re-trying requests responsibly.
Compare rate limits by API
Shopwaive APIs use several different rate-limiting methods. They’re described in more detail below, but these are the key figures in brief:
Shopwaive API (REST)
Request-based limit
2 requests / s
20 requests / s
Tip: Should your application need to request a custom API rate limit plan, contact sales to learn more at support@shopwaive.com
Enterprise limit
If you purchase a high thru-put enterprise API throttling limit for the Shopwaive REST API, you will receive an key-value pair from our Sales team to include in your request header.
For enterprise API requests, in addition to the added header you will include the /v2 suffix to each route defined in the REST API documentation to make requests.
For example, to make requests to the POST customer route /api/customer using Enterprise rate limits you will use the /v2/api/customer route instead, and add the key-value header x-shopwaive-api-enterprise.
Header
X-Shopwaive-API-Enterprise
Enterprise rate limit API key for store (required)
Rate limiting methods
Shopwaive uses different methods for managing rate limits. Different APIs use different methods depending on use case, so make sure you understand the various types of rate limits your apps will encounter:
Request-based limits
Apps can make a maximum number of requests per second. For example: 2 requests per second. Each request counts equally, regardless of how much or how little data is returned.
This method is used by the Shopwaive REST API.
Avoiding rate limit errors
Designing your app with best practices in mind is the best way to avoid throttling errors. For example, you can stagger API requests in a queue and do other processing tasks while waiting for the next queued job to run. Consider the following best practices when designing your app:
Optimize your code to only get the data that your app requires.
Use caching for data that your app uses often.
Regulate the rate of your requests for smoother distribution.
Include code that catches errors. If you ignore these errors and keep trying to make requests, then your app won’t be able to gracefully recover.
Use metadata about your app’s API usage, included with all API responses, to manage your app’s behavior dynamically.
Your code should stop making additional API requests until enough time has passed to retry. The recommended backoff time is 1 second.
Last updated