Bino Supply · Mobility
Bring ride discovery, assignment, ride-state updates, and post-order actions into your own app through one mobility-ready supply API.
Bino Supply Mobility is built for teams that want to integrate ride-hailing and transport workflows without directly owning the full ONDC ride state machine. These APIs are also being shaped to be agent-native, so AI agents can understand the domain, form useful queries, and make supply calls with less manual API orchestration.
Mobility API
Ride hailing
Overview
What this API is meant to unlock.
The mobility surface is for on-demand and scheduled ride experiences where the workflow does not end at booking. A serious mobility integration needs ride search, selection, booking confirmation, live fulfillment movement, support for ride updates, status checks, cancellations, and post-order actions. This API surface is meant to support that broader operational scope.
Why this matters
Mobility is one of the hardest categories to productionize because the protocol conversation continues well after the original user action. A good API here must therefore be product-shaped and operations-aware, not just technically compliant.
Capabilities
A deeper look at the supply surface.
These are the kinds of workflows this domain page is meant to prepare for as the Bino Supply program opens up in a more structured way.
Ride search across product shapes
Support on-demand and scheduled ride discovery with enough structure for a partner app to present the right ride options and journey context.
Selection and booking confirmation
Carry the customer from discovery into the selected ride path and through booking confirmation in a cleaner application-facing model.
Live ride-state handling
Expose ride progression, seller callbacks, and fulfillment-stage movement so the consuming app can stay aligned with the actual ride state.
Track, status, and cancellation
Support the practical ride actions that product teams care about after booking, including ride refresh, tracking, and cancellation-style flows.
Ride updates and post-order actions
Leave room for stop updates, confirmations, post-order tips, and other ride changes that appear in real transport products.
Operations and support readiness
Feed ride-state, outcomes, and event evidence into the business layer so mobility can be supported operationally rather than treated as a black box.
How the program opens up
Start with domain intent, then go deeper into implementation.
The exact technical shape will depend on the approved partner use case, but this is the practical progression we expect teams to move through.
Search and choose
The app discovers ride options and moves the chosen path into the booking lane.
Create the ride order
The booking and confirmation flow establishes the ride in the system and begins the lifecycle that continues after the first customer action.
Monitor the live journey
Seller callbacks and ride-state changes can keep the product updated as the trip evolves.
Handle post-booking actions
The integration can support actions like ride status refresh, cancellation, tracking, stop changes, and post-order workflows.
Where this fits best.
Different teams will use the same Bino Supply surface differently. These examples are the kinds of product and business situations this API page is designed to support.
Consumer ride experiences
Build branded ride-booking flows without rebuilding the underlying ONDC interaction model.
Operator and dispatch tools
Expose ride state, fulfillment progression, and ride actions to internal teams managing day-to-day transport operations.
Partner mobility layers
Let another app or business add rides as a product category while keeping the deeper lifecycle handling centralized.
Support-first ride workflows
Give customer support or operations teams access to ride state and event context inside the same system.
FAQ
Why is mobility more than a simple booking API?
Because the ride continues after the booking moment. Assignment, live movement, ride-stage callbacks, cancellations, and post-order actions all matter to the real product experience.
Can this support both on-demand and scheduled rides?
That is the intended shape of the mobility surface. It is designed for ride workflows that can vary by category while still using one deployment model.
Who benefits most from this API?
Product teams building mobility experiences, dispatch or operations tools, and businesses that want ride capability inside a larger application are strong fits.
Will there be route-level docs later?
Yes. This page is intentionally about domain understanding and fit. Detailed technical documentation comes after access and onboarding are in place.
Next step
Register interest for this domain, then move into org-level access.
We are deliberately separating domain understanding from credentials. Once the signup flow is in place, partners will be able to request this API surface directly and move into the right access, onboarding, and implementation path.