Usage & Limits

Pagination

List endpoints that return large result sets support pagination via the page, per_page, and offset query parameters. per_page controls how many items are returned per page (up to 100). Use page (1-based) or offset (0-based item skip count) to advance through the result set — do not use both in the same request. Iterate by incrementing page until a response returns fewer items than per_page.

Rate limits

RM API keys are rate-limited to 60 requests per minute by default. Exceeding this limit returns 429 Too Many Requests. The limit resets on a rolling one-minute window.

Every response tells you where you stand, so you never have to guess or spend a request finding out:

Header	Meaning
X-RateLimit-Limit	Requests allowed per window for the key you used.
X-RateLimit-Remaining	Requests still available in the current window. Never negative.
X-RateLimit-Reset	Unix timestamp (seconds) when the window frees up.

The request carrying the headers is itself counted, so an idle key's first response reports one fewer than the limit.

A 429 carries the same three headers plus Retry-After, the number of seconds to wait. Prefer Retry-After over your own backoff schedule when it is present — it is the actual reset, not an estimate.

If you receive a 429 and no Retry-After, wait before retrying. The recommended strategy is exponential backoff: after the first failure wait 1 second, then double the delay on each subsequent retry (2 s, 4 s, 8 s, …), up to a reasonable maximum (e.g. 60 seconds). Adding a small random jitter (±10–20% of the wait time) prevents multiple concurrent clients from retrying in lockstep.

If your integration regularly reaches the limit, consider batching requests (e.g. using GET /preferences or PUT /preferences for multiple listings at once) or contact Wheelhouse to discuss a higher limit.

GET /usage reports volumes, error rates, and response times over a window of up to 7 days, broken down by day, by endpoint, and by API key. It is cached for a few minutes, so poll it on the order of minutes, not seconds, and read generated_at to see how fresh a response is. Live rate-limit headroom is on the X-RateLimit-* headers of any response — they are current as of that request and cost nothing extra.