Welcome to Lyft's API documentation. Lyft's API enables developers to programmatically interact with Lyft's rider and driver network, enabling them to transport their customers with a smile.
If you haven't used Lyft before—or are unfamiliar with ridesharing—check out the Lyft homepage and the Lyft Developers Portal. In summary, Lyft matches drivers with passengers who request rides through their Lyft smartphone app...or through your application or service, via the Public API.
- Lyft has an expansive network of passengers and drivers across the United States, and the network continues to grow by leaps and bounds.
- The Lyft API features and support are growing commensurately.
- Lyft's API follows modern RESTful convention and is simple to use.
If you're new to Lyft, check out the Glossary for commonly used terms.
The Lyft API is extensively annotated via Swagger/OpenAPI. Each endpoint page features a link to its spec. You can also find the full specification here.
In order to query the Lyft API, you must sign up for Lyft Developer Program. From there you can create multiple applications, each of which associated with distinct client credentials necessary to access the API via OAuth2. Check the Authentication guide for more detail on using these credentials to query the API. In summary, every Lyft API request expects an
Authorization header with an appropriately scoped OAuth2 token.
The Lyft API has default Rate Limits. If you reach the rate limit for a given endpoint you'll get an HTTP 429 response. Individual rate limits are listed under each endpoint in the Reference section. You can also get rate limit information via the API's response headers, as detailed in the Rate Limits section.
Timeouts and Retry Guidance
The Lyft API should return a response within 10 to 15 seconds. If your application has retry logic, please wait 15 seconds; it's possible your response is in-flight if you retry beforehand. Minimizing retries also serves to limit the possibility of hitting rate limits.
It's generally a good idea to test your applications before pushing them to production. To that end, the Lyft API offers a Sandbox environment for API testing, where you can accurately simulate API conditions without actually requesting Lyft rides. There are a number of Sandbox-specific APIs to set environmental conditions that are difficult to consistently reproduce in production; like limiting
ride_type categories or elevating
primetime rates. Check out the Sandbox guide for more.
Every response from the Lyft API includes useful extra fields in the HTTP header, described below:
||integer||the number of calls remaining for the endpoint and time limit belonging to this request|
||integer||the overall limit for the endpoint and time limit belonging to this request|
||string||a unique identifier for this request|
||string||a base64-encoded SHA256 hash of a webhook payload; used to verify message integrity|
Our documentation includes a built-in support system that allows public support queries; you can check it out here. If your support request hasn't been answered by the public responses there, feel free to submit a question.
Please Log Your Request-IDs!
The aforementioned header field
Request-ID is unique for every single response from the Lyft API. If your application model allows it, please consider logging this value. When you have support questions, providing associated
Request-IDs can make issue diagnosis and response significantly faster.