WellnessLiving · Rate Limits

Wellnessliving Rate Limits

WellnessLiving's official OpenAPI specification (github.com/wellnessliving/openapi) embeds a machine-readable `x-rate-limit` extension directly on most operations, so - unusually for a partner-gated API - numeric limits are confirmed straight from the published spec rather than inferred. Of 324 documented paths in the production build, 458 operation-level rate-limit entries were found (some operations expose both GET and POST): the overwhelming majority (454) are capped at 200,000 requests per hour, with a small number of high-load schedule/class-listing operations further restricted to 3,000 requests per 5 minutes. The API additionally supports an opt-in `X-Error-Rules` request header that converts internal error statuses into real 4xx HTTP codes (by default every response is HTTP 200 with the error encoded in the JSON body), which matters for building correct retry/backoff logic against throttling responses.

Wellnessliving Rate Limits is the machine-readable rate-limit profile for WellnessLiving on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 4 rate-limit definitions, measuring requests and n/a.

The profile also includes 2 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Fitness, Wellness, Rate Limiting, and Quotas.

4 Limits Throttle: 429
FitnessWellnessRate LimitingQuotas

Limits

Standard Endpoint Limit application
requests
200000 per 3600 seconds (200,000/hour)
The default `x-rate-limit` value found on 454 of 458 rate-limited operations in the official OpenAPI spec, including authentication (JwtToken), payments (Thoth/WlPay), and reporting (Thoth/ReportCore, Thoth/ExplorerSearch) endpoints.
High-Traffic Schedule Endpoint Limit application
requests
3000 per 300 seconds (3,000/5 minutes)
A tighter limit applied to a small number of heavily-polled endpoints, confirmed on Wl/Schedule/ClassList/ClassList(.json/68) and Wl/Schedule/ClassView/ClassView.json.
Business Self-Signup Limit ip and global
requests
not numerically published
POST /Wl/Business/Business.json is documented as "Rate-limited per IP and globally to prevent abuse" in the official spec description, without a published numeric figure.
Error-to-HTTP-Code Conversion request
n/a
opt-in via X-Error-Rules header
By default every WellnessLiving API response is HTTP 200, with success/failure encoded in the JSON body. Setting the `X-Error-Rules` header (e.g. to `default`) makes matched error statuses surface as real 400/403/404 HTTP codes instead, which is required to build standard HTTP-status-based retry/backoff handling, including for throttling.

Policies

Approval Gate
Rate limits apply per registered Application ID, issued only after WellnessLiving's Integrations Team approves an API Access Questionnaire and both parties sign an NDA and API Agreement.
Backoff Strategy
Clients should implement exponential backoff with jitter on repeated throttling and honor any `Retry-After`-equivalent guidance from WellnessLiving Support for a given application, since the public spec does not itself document a Retry-After response header.

Sources