Bounds on limit and offset

What's new

The limit and offset query parameters on the list endpoints now declare numeric bounds. limit accepts at most 300 across 26 endpoints, and offset must be 0 or greater across 24 of them. Both were previously plain integers with no stated range.

The lower bound on limit is written as exclusiveMinimum: 1, so a value must be greater than 1. get_orders is the one exception and uses minimum: 1, which does accept 1. If you page one record at a time, limit=1 now fails validation everywhere except get_orders.

Impact

Requests that exceeded the old, unstated caps were already being rejected or clamped by the API. What changed is that generated clients and schema validators can see the range, so an out-of-bounds value can be caught before the request goes out.

Changes

Resource	Change
get_achievements, get_campaigns, get_coupons, get_creators, get_daily_rewards, get_disputes, get_fraud_alerts, get_item_categories, get_items, get_leaderboards, get_leaderboard_members, get_locales, get_news_list, get_pages, get_payments, get_player_subscriptions, get_price_templates, get_segments, get_store_promotions, get_stores, get_translation_glossaries, get_user_coupons, get_user_promotions, get_videos	limit must be greater than 1 and at most 300, default unchanged at 10
get_webhooks	limit must be greater than 1 and at most 300, default unchanged at 300
get_orders	limit must be between 1 and 300, default unchanged at 10
The 24 list endpoints above, excluding get_price_templates and get_translation_glossaries	offset must be 0 or greater

Upgrade

• Check any code that passes limit=1. On every endpoint except get_orders the spec now rejects it, and you need limit=2 or a switch to get_orders-style cursor paging.
• Clamp a user-supplied page size to 300 before sending it, rather than relying on the server to trim it.
• Regenerate clients to pick the bounds up in your generated validation.

Need help?
Contact our integration team at [email protected]