Do you have a status page?
Yes. You can review the status for all our systems on the status page.
How is your infrastructure deployed?
We run all our services on the Google Cloud Platform.
How does authentication work?
All requests to the rideOS APIs need to be sent with an API key for authentication. You can create and manage API keys in your user settings in the rideOS dashboard.
To authenticate a request to the API, send an API key as the X-Api-Key header:
What is the rate limit for the rideOS APIs?
You can review the rate limits for the various rideOS APIs here.
I received an HTTP error 429, what does this mean?
An HTTP error 429 returned by one of the rideOS APIs indicates that the user has sent too many requests in a given amount of time. You can review the rate limits for the various rideOS APIs here.
In this situation, we recommend retrying your requests implementing the exponential backoff strategy. A few seconds delay should be sufficient. For specific endpoints, shorter or longer intervals may be appropriate.
What HTTP status codes can I expect in the response?
We return different HTTP status codes depending on the success or failure of the API request. Different status codes have different meanings:
- 200: A successful response
- 400: The request was invalid. Please check that all the input parameters have been set properly.
- 401: The request was not correctly authorized. Please ensure you passed in the correct API Key.
- 403: This is returned when the user does not have permission to access the resource.
- 429: An HTTP error 429 returned by one of the rideOS APIs indicates that the user has sent too many requests in a given amount of time. You can review the rate limits for the various rideOS APIs here. In this situation, we recommend retrying your requests implementing the exponential backoff strategy. A few seconds delay should be sufficient. For specific endpoints, shorter or longer intervals may be appropriate.
Dispatch API FAQs
Is there a way to receive event notifications?
Currently, the Dispatch API does not support server-side notifications like webhooks.
To stay up to date with any state changes, we recommend polling endpoints like
GetVehicleState regularly (roughly once every 1 to 10 seconds).
What optimization metrics are considered for assignment of vehicles to tasks?
You can configure the optimization metric in the Dispatch API at the fleet level. The two options are:
RIDE_HAIL- Minimizes overall rider wait times and ride times.
GOODS- Minimizes total time vehicle spends traveling.
Can I ensure that a particular vehicle will be assigned to a particular task?
When calling the
CreateTask endpoint, you can set the optional
vehicleFilters to a specific vehicle id. This will assign that particular vehicle to the trip. Note that any trips already assigned to that vehicle remain assigned.
When using the Dispatch API, which events trigger a re-optimization of the fleet?
Events that trigger a re-optimization of the fleet plan include:
- a new task is created
- a new vehicle is created
- a vehicle starts or stops accepting tasks
- a task is completed or cancelled
- a task's pickup or dropoff location is modified
- a task is rejected (via RejectTask)
- a trip is unassigned (via UnassignTask)
- a re-optimization is explicitly requested (via TriggerOptimization)
No reoptimization occurs for position updates of a vehicle.
How can I see the trip history for a specific rider?
GetTasksByTime endpoint returns all the tasks in a fleet by their creation and completion time. The requestorID is also returned in the response.
Thus, you can call this endpoint and then filter all the trips by the requestorID at your end.
Fleet Planner API FAQs
What is the timeout for calls to Fleet Planner?
The timeout for calls to the GetPlan endpoint in the Fleet Planner API is 60 seconds.
Is there a maximum number of vehicles and trips that can be sent to Fleet Planner concurrently?
The default limit for Fleet Planner is 50 concurrent vehicles and 50 concurrent trips. Talk to us if you need a higher limit!
Constraint Data API FAQs
Is there a limit on the number of constraints I can configure?
No, there is no limit enforced in the Constraints Data API.
What are operational and avoid constraints in the Constraint Data API?
A vehicle can travel in any area that is classified as operational. It avoids travel in an area that is classified as avoid.
Operational constraints include area constraints, and path constraints. They are also referred to as operational areas and paths.
Avoid constraints include area constraints, path constraints, and turn constraints. They are also referred to as avoid areas, avoid paths and avoid turns.
What happens if I have both operational and avoid constraints?
Routes will attempt to stay within operational areas/paths. Routes will also attempt to stay out of avoid areas/paths/turns. If an area/path is both operational and avoid, then it is treated as an avoid constraint.
If you don't supply any operational constraints, the whole map is considered to be operational.
Do you support hard and soft constraints?
When working with the low-level Routing APIs (the Path API and the ETA API), the constraints configured via the Constraints Data API are handled as soft constraints. They are encoded as a very high cost compared to routes that do not break a constraint. The response will indicate whether any constraints were violated.
In the Ridehail and Fleet Planner APIs, which rely on the Routing APIs under the hood, all constraints are being treated as hard constraints.
How can I add a vehicle-specific constraint, such as the maximum speed of a vehicle?
We currently do not support vehicle-specific constraints.
What is the use case for "operational path" constraints?
A vehicle with operational path constraints is only allowed to travel on the operational paths. An example use case is a vehicle that follows a fixed route in a loop.