Rate Limits
Rate limit tiers, headers, and best practices for the WedStay API.
Rate Limits
The WedStay API uses rate limits to ensure fair usage and platform stability.
Tiers
| Free | Pro and Partner | |
|---|---|---|
| Read requests | 100 / day | 10,000 / day |
| Burst limit | 10 / minute | 60 / minute |
Venue detail lookups (GET /api/v1/venues/{slug}) | 20 / day | 20 / day |
| Inquiry submissions | 5 / day | 5 / day |
| Price | $0 | Contact us |
Every window rolls: the burst limit counts the last 60 seconds and the daily limits count the last 24 hours. The venue detail limit keeps the full catalog from being copied one venue at a time and is counted separately from the daily read limit.
List endpoints return at most 100 results per page (limit, default 20). The keyless MCP server's search_venues tool returns at most 50 per call.
Rate limit headers
Every API response carries rate limit headers:
| Header | Description |
|---|---|
X-RateLimit-Limit | Requests allowed per minute: your key's tier limit (10 on Free, 60 on Pro and Partner) |
X-RateLimit-Remaining | Requests left in the current one minute window |
X-RateLimit-Reset | When the window resets, as a Unix timestamp in seconds |
Retry-After | Seconds until you can retry (only on 429 responses) |
A request sent without an API key, such as GET /api/v1/openapi.json or a 401 for a missing key, is answered by the per IP limit that protects the whole site: 400 requests per minute per IP address, so X-RateLimit-Limit is 400 (and the reset is also in Unix seconds). A 401 for an invalid or revoked key carries no rate limit headers: the key is checked before any limit is counted.
Example headers
429 Response
When you exceed a rate limit, you'll receive a 429 Too Many Requests response:
The venue detail and inquiry limits answer with their own codes, venue_detail_rate_limit_exceeded and inquiry_rate_limit_exceeded. See Errors.
Best practices
- Cache responses. Venue data changes infrequently. Cache search results for at least 5 minutes.
- Use pagination. Don't fetch all venues at once. Use the
cursorandlimitparameters. - Check headers. Monitor
X-RateLimit-Remainingto avoid hitting limits. - Implement backoff. On 429 responses, wait for the
Retry-Afterduration before retrying. - Batch where possible. Use search filters to get the data you need in fewer requests.