Experimental public beta

Read bike geometry and modeled posture scores as JSON.

Explore Rider Height's bike catalog, geometry provenance, and modeled posture comparisons through a read-only v1 JSON API. No API key or account is required. The API uses endpoint-specific response caching. Its current abuse control is a best-effort per-runtime threshold, not a durable global limit. There is no SLA or contractual quota.

Version

Authentication

No API key or account

Abuse control

Best effort per runtime

Caching

Bikes public; fit private, no-store

GET/api/v1/bikes

List public bike summaries. Supports search, category filtering, and a capped limit.

q=yamahacategory=nakedlimit=25

Open sample JSON

GET/api/v1/bikes/{slug}

Read one bike with manufacturer, available public asset metadata when present, geometry measurements, field provenance, verification state, and web/embed links.

Open sample JSON

GET/api/v1/fit

Return modeled posture scores for one to five bikes using rider height and inseam. Omitted measurements default to heightMm 1830, inseamMm 855, and weightKg 82. Supplied values are never replaced silently. Supported profile ranges are inclusive: heightMm 800–2500, inseamMm 400–1300, and weightKg 20–250. inseamMm must be less than or equal to heightMm, and omitted defaults participate in the same cross-measurement rule. An invalid supplied measurement or invalid composition returns 400 with the invalid_rider_measurement code. Optional weight is echoed as profile context but does not affect the current posture score. Each result includes geometry verification, evidence basis, and bike links.

slugs=slug-a,slug-bheightMm=1830inseamMm=855weightKg=78

Open sample JSON

Browser access and CORS

Browser JavaScript from any origin can read responses to credential-free GET requests through Access-Control-Allow-Origin: *. Allowed methods are GET, OPTIONS. HEAD is explicitly rejected with 405 Method Not Allowed; Allow remains GET, OPTIONS. Use the canonical base URL; alias hosts redirect before a v1 handler adds its CORS, version, or cache headers.
For a cross-origin request, Content-Type is the only non-safelisted request header the API advertises. Authorization triggers preflight; because it is not granted, a conforming browser should not send the subsequent GET. CORS does not reject or authenticate same-origin or non-browser requests.
Browser code can read the exposed response headers X-API-Version, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, Retry-After.
For cross-origin browser calls, use credentials: "omit". With credentials: "include", a browser may attach matching cookies to the HTTPS request and send it, while CORS prevents cross-origin code from reading the response. On the canonical host, application middleware replaces the Cookie value with an empty string before forwarding exact /api/v1 requests and descendants to their route handlers. This does not stop upstream edge or proxy infrastructure from receiving the original request, delete browser cookies, or erase logs. Access-Control-Allow-Origin: * is used and Access-Control-Allow-Credentials is omitted.
The current v1 handlers do not authenticate callers. Only Cookie contents are cleared; other headers, including Authorization from same-origin or non-browser clients, are forwarded and currently ignored by the handlers.
A future authenticated v1 route must revisit this namespace-wide Cookie policy and add route-level authentication, private, no-store caching, and an intentional CORS policy.
Each documented v1 handler answers preflight with 204, Access-Control-Max-Age: 600, and Cache-Control: public, max-age=600. This 204 confirms only the CORS policy; it does not prove feature availability or subsequent GET success.
This is checked-in application behavior, not hosted proof. Hosted verification remains required for the deployed route-handler view, a cross-origin GET and preflight, response and cache headers, and upstream request or error logging.

Caching and request privacy

The application sets successful bike list and detail responses to Cache-Control: public, s-maxage=300, stale-while-revalidate=3600.
The application sets successful fit responses to Cache-Control: private, no-store. Errors produced by the documented handlers use Cache-Control: no-store.
GET /api/v1/fit puts slugs, heightMm, inseamMm, and weightKg in the request URL. Those values can appear in browser history and in infrastructure, proxy, and access logs.
private, no-store controls response caching; it does not erase request URLs, browser history, or logs.
Production log retention and deletion behavior has not been verified.

Response contract

Successful JSON GET responses generated by the documented v1 handlers use meta and data top-level keys.
Errors generated by those handlers use error: { code, message } with the relevant HTTP status.
Responses generated by the documented v1 handlers include `X-API-Version: v1`.
The best-effort threshold may return `429` plus `Retry-After` and rate-limit headers. It is not a durable, global, or contractual quota.
Bike detail assets expose available public asset metadata when present, including image URLs, source/license hints, dimensions, and content type; storage bucket/key internals are omitted.
Fit responses expose model.weightAffectsScore as false; optional weight is echoed for profile compatibility.
Fit result rows include modeled score data and geometry verification. evidence.dataBasis is the data basis { id, label } and describes the geometry evidence, while evidence.layoutBasis is the layout basis { id, label, detail } and identifies the rider-contact placement used by the model. verification is the canonical individual-bike verification state; the layout basis is separate from it. None of these fields is a comfort, safety, or purchase verdict. Rows also include imageUrl and link metadata for rendering bike cards without a follow-up detail request.