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. Every Bino Supply API is agent-native: an AI agent reads the domain, forms the query, and places the supply call itself — no glue code in between.
Mobility API
Ride hailing
Overview
What this API unlocks.
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. The API carries 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.
The workflows teams build on this domain most often, and what the API hands you for each one.
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.
No black-box rides
Ride state, outcomes, and event evidence land in your business layer as they happen, so a rider question has an answer before it becomes a ticket.
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.
Teams build very different products on the same Bino Supply API. Here is where it earns its place most often.
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?
Yes. Ride workflows vary by category, and the mobility API carries that variation on one deployment model — you integrate once and add categories without re-plumbing.
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.