Comment on page
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.
Shopwaive APIs use several different rate-limiting methods. They’re described in more detail below, but these are the key figures in brief:
API | Rate-limiting method | Standard limit | Enterprise limit |
|---|---|---|---|
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 [email protected]
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. key | value |
|---|---|
X-Shopwaive-API-Enterprise | Enterprise rate limit API key for store (required) |
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:
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.
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 modified 26d ago