specification: API Commons Rate Limits specificationVersion: '0.1' provider: lyft providerId: lyft created: '2026-05-04' generated: '2026-09-17' modified: '2026-09-17' method: searched source: openapi/*.yml; https://www.lyft.com/developers (302 to login); https://help.lyft.com/business/hc/en-us; live responses from api.lyft.com and gbfs.lyft.com description: 'Lyft publishes no rate limits for its API. This file replaces a 2026-05-04 scaffold that asserted 10/100/1000 requests per minute across Free, Professional and Enterprise tiers with monthly quotas; none of those numbers was ever published by Lyft, and Lyft publishes no such tiers (see plans/lyft-plans-pricing.yml). An honest zero is the finding: an integrator cannot learn the throttling contract before signing one.' limit_count: 0 limits: [] headers: limit: null remaining: null reset: null retryAfter: null policy: null headers_evidence: No RateLimit-*, X-RateLimit-* or Retry-After response header is declared on any of the 18 published operations, and none was observed on any live anonymous response. responseCodes: throttled: null responseCodes_evidence: No operation in openapi/*.yml declares a 429 response. observed: - host: www.lyft.com observation: Repeated anonymous requests returned HTTP 429 with an empty body and no RateLimit-* or Retry-After header during well-known probing on 2026-09-17. reading: The website edge does throttle, and it signals nothing a client could act on. This is edge behaviour on the marketing host, not a documented API limit. - host: gbfs.lyft.com observation: 'No throttling observed across 30+ anonymous feed requests; every GBFS feed advertises ttl: 60, which is a polling-cadence hint rather than a rate limit.' reading: ttl 60 is the closest thing Lyft publishes to a documented client cadence, and it applies only to the GBFS surface. policies: [] gaps: - No published limit for any tier, key or endpoint. - 'No runtime signal: an agent cannot see how close it is to a limit, and on exhaustion has no Retry-After to honour.'