Hoppa Partner

## Sections
• [Ride Status](https://developers.hoppa.com/ride-status.md): The Ride Status section in the Default project API allows users to retrieve detailed information about a specific partner ride. By accessing this section, users can easily track and manage essential data related to a particular ride within their application, enabling efficient monitoring and control of partner ride details.
• [Update ride](https://developers.hoppa.com/update-ride.md): The “Update ride” API allows users to modify and adjust existing ride information, such as passenger details, locations, vehicle class, and additional services. Users can seamlessly update and manage ride specifics within the API to ensure accurate and up-to-date ride information. Update ride is supported only for one way, hourly and roundtrip rides. It is not applicable for multiday, mutivehicle, train and ride hailing rides.
• [About Hoppa APIs](https://developers.hoppa.com/about-hoppa-apis.md): Hoppa provides a set of APIs designed to integrate with partner systems for ride booking, management, and related services. #### **API Endpoint Allocation** API endpoints are provided **per partner and per API**, allowing Hoppa to manage computational resources based on each partner’s volume and specific implementation requirements. #### **Sandbox Environment** A **sandbox environment** is provisioned for each partner to support **development and testing** before production deployment. Sandbox endpoints will be shared during the development phase. **Available APIs** The following **RESTful APIs** are available to support ride booking and management: * **Ride Quote API** API allows users to retrieve pricing information for potential rides. By utilizing this feature, users can quickly obtain quotes for partner rides, facilitating cost estimation and informed decision-making in transportation planning. * **Reservation API** The Reservation API is applicable only for `train` as the vehicle class. Reserves a train ticket for the given `quote_id` . Returns the total price of the ride with breakup. * **Ride Order Creation API** API allows users to schedule transportation services for one-way, round-trips and hourly rides by providing essential details such as pickup and drop-off locations, passenger information, and vehicle class. API Creates a booking. * **Ride Order update API** The Ride Update API allows updating all details of an existing ride booking, including, Pickup and drop-off locations, date and time, vehicle type, flight information etc * **Ride Cancellation API** Allows cancellation of a scheduled ride. * **Ride Order Status API** Retrieves the current status of an existing booking. * **Update Passenger API** Updates passenger information, including contact details and luggage specifications. * **Trip Status** Allows adding of special instructions to the Ride order. * **Ride Detail** Allows to retrieve all the details of the ride
• [Ride Quotes](https://developers.hoppa.com/ride-quotes.md): The “Ride Quotes” API allows users to retrieve pricing information for potential rides. By utilizing this feature, users can quickly obtain quotes for partner rides, facilitating cost estimation and informed decision-making in transportation planning. Quotes can be obtained for: Point to Point, a.k.a. one way rides. A point-to-point (or one-way ) ride refers to a trip with a single pickup and drop-off location, without a scheduled return. In such cases, the request does not include a return_time parameter, and pricing is calculated based solely on the one-way journey. If the time is now, request is treated as Ride hailing Round trip rides. A ride is considered a round trip if the request includes the return_time parameter. The presence of this parameter indicates that the ride is not one-way. In such cases, the returned price will reflect the round-trip fare. Additionally, booking a round-trip ride may offer a discount compared to booking two separate one-way trips. Duration based rides (hourly). An hourly ride is basically a ride based on duration , and service will be rendered for the duration quoted. It is expected the drop off address will be in close proximity to the pickup address. To get a quote and create a ride based on duration, the to field must be the same as the from field, and an additional field duration must be provided to indicate the number of minutes requested. Multi day rides. Multi-day rides are represented as a sequence of individual trip segments , each corresponding to a leg of the journey. These segments are defined using the trips array in the request payload or ride configuration. If the trips array is present , the ride is treated as a multi-day journey composed of discrete legs. If the trips array is not provided , the ride defaults to one of the standard ride types Point to point, aka one-way, Round-trip, Hourly Train Booking Train Booking are ride bookings with vehicle class as Trains , you can search for train schedule in close proximity to your requested from and to location and you journey datetime, The API returns a list of train schedules from which you can book a oneway/roundtrip train by picking you convinient schedule. Ride Hailing Ride Hailing rides are on demand rides or Asap one way ride. you need to provide the time as now to search for the real time availability for the ride.
• [Reservation](https://developers.hoppa.com/reservation.md): The Reservation API is used to reserve a train ticket for a given schedule associated with a `quote_id`. Each reservation is valid for 9 minutes from the time of request, and there is a one-to-one relationship between a train reservation and the `quote_id` in the quote response. A new `quote_id` must be used for every reservation request, and the API returns the reservation details along with the total price of the ride
• [Book a ride](https://developers.hoppa.com/book-a-ride.md): The “Book a ride” allows users to schedule transportation services for one-way, round-trips and hourly rides by providing essential details such as pickup and drop-off locations, passenger information, and vehicle class. Point to Point, a.k.a. one way rides. A point-to-point (or one-way ) ride refers to a trip with a single pickup and drop-off location, without a scheduled return. In such cases, the request does not include a return_time parameter, and pricing is calculated based solely on the one-way journey. If the time is now, request is treated as Ride hailing. Round trip rides. A ride is considered a round trip if the request includes the return_time parameter. The presence of this parameter indicates that the ride is not one-way. In such cases, the returned price will reflect the round-trip fare. Additionally, booking a round-trip ride may offer a discount compared to booking two separate one-way trips. Duration based rides (hourly). An hourly ride is basically a ride based on duration , and service will be rendered for the duration quoted. It is expected the drop off address will be in close proximity to the pickup address. To get a quote and create a ride based on duration, the to field must be the same as the from field, and an additional field duration must be provided to indicate the number of minutes requested. Multi day rides. Multi-day rides are represented as a sequence of individual trip segments , each corresponding to a leg of the journey. These segments are defined using the trips array in the request payload or ride configuration. If the trips array is present , the ride is treated as a multi-day journey composed of discrete legs. If the trips array is not provided , the ride defaults to one of the standard ride types Point to point, aka one-way, Round-trip, Hourly Train Booking A train booking as represented as trips , need to provide the quote id for each trip. Also its required to provide details of all passenger in the passengers array , with the booking fields that are mandatory which is sent in the quote response. Ride Hailing Ride Hailing rides are on demand rides or Asap one way ride. you need to provide the time as now to make the booking as ride hailing
• [Update ride](https://developers.hoppa.com/update-ride-1.md): The “Update ride” API allows users to modify and adjust existing ride information, such as passenger details, locations, vehicle class, and additional services. Users can seamlessly update and manage ride specifics within the API to ensure accurate and up-to-date ride information. Update ride is supported only for one way, hourly and roundtrip rides. It is not applicable for multiday, mutivehicle, train and ride hailing rides.
• [Cancel ride](https://developers.hoppa.com/cancel-ride.md): The Cancel ride section of the API empowers partners to efficiently manage and update ride statuses within the system by canceling specific rides. By utilizing this functionality, users can swiftly make real-time adjustments to their ride information, providing them with enhanced flexibility and control over partner-related actions.
• [Ride Status](https://developers.hoppa.com/ride-status-1.md): The Ride Status section in the Default project API allows users to retrieve detailed information about a specific partner ride. By accessing this section, users can easily track and manage essential data related to a particular ride within their application, enabling efficient monitoring and control of partner ride details.
• [Passenger Update](https://developers.hoppa.com/passenger-update.md): The Passenger Update section allows users to modify and update passenger details for specific rides within the Hoppa Partner API. By enabling changes to passenger information such as names, contact details, and luggage counts, users can ensure personalized and accurate transportation experiences for their clients. This section empowers users to manage passenger data seamlessly and facilitate smooth communication during rides. Passenger Update is only applicable for prebooked rides and currently does not support train and ride hailing rides.
• [Add Note](https://developers.hoppa.com/add-note.md): The Add Note section allows users to update and manage notes associated with specific partner rides within the Hoppa Partner API. By utilizing this functionality, users can efficiently maintain and communicate detailed information related to partner rides, fostering seamless collaboration and enhancing operational efficiency.
• [Trip Status](https://developers.hoppa.com/trip-status.md): The "Trip Status" section of the Hoppa Partner API allows users to retrieve real-time updates on the status of trip details associated with their account. With this functionality, users can monitor and track the progress of specific trips, enabling them to make timely decisions and adjustments as needed.
• [Ride Detail](https://developers.hoppa.com/ride-detail.md): The Ride Detail section provides comprehensive information about a specific ride, including details about the passenger, vehicle, price, and dispatches. Users can retrieve detailed data about a ride's origin, destination, duration, and additional pertinent information to facilitate effective management and tracking of rides within the system.
• [Authentication](https://developers.hoppa.com/webhooks/authentication.md): Hoppa calls into the partner system to get the access token using the client id and client secret
• [Provide driver and vehicle details](https://developers.hoppa.com/webhooks/provide-driver-and-vehicle-details.md): The webhooks below are based on Hoppa's specification. However, Hoppa is dedicated to streamline integration and is flexible to adapt to partner's technology and API capability. Hoppa is open to use partner's existing webhook specification. The authentication mechanism for accessing the API is subject to agreement with the integration partner. The specific method—such as API key or OAuth 2.0, will be determined and formalized during the integration planning phase. This callback is triggered when a driver and vehicle have been assigned to a ride. It delivers the relevant details to the partner system, enabling real-time updates and preparation for ride fulfillment.
• [Send driver events and location details](https://developers.hoppa.com/webhooks/send-driver-events-and-location-details.md): The webhooks below are based on Hoppa's specification. However, Hoppa is dedicated to streamline integration and is flexible to adapt to partner's technology and API capability. Hoppa is open to use partner's existing webhook specification. The authentication mechanism for accessing the API is subject to agreement with the integration partner. The specific method—such as API key or OAuth 2.0, will be determined and formalized during the integration planning phase. This callback provides details on changes of driver status and location detail updates on a periodic basis as the trip is being done. The frequency of driver location updates is configurable and should be agreed upon during integration. While some platforms (e.g., Uber) send location data every 4 seconds, such frequency may be considered excessive depending on the use case and operational constraints. Collected data can be batched and transmitted at a different interval (e.g., every 60 seconds, via the webhook
• [Send Final Fare](https://developers.hoppa.com/webhooks/send-final-fare.md)
• [Vehicle Mapping](https://developers.hoppa.com/enumerations/vehicle-mapping.md): Vehicle Mapping included in the Availability response payload, acts as a unique reference used to categorize vehicle groups. It supports consistent mapping across different locales, enabling effective integration." Review Hoppa Vehicle Classes Refer to the documentation to understand each vehicle class (e.g., Business, MPV, First Class, Minibus, Limo, Shuttles). Focus on definitions based on comfort, use case, passenger capacity, and typical vehicle models or equivalents. For more details, you can also refer to Hoppa’s Fleet Overview . Create a Mapping Matrix Map your local vehicle types to the closest Hoppa vehicle classes by comparing key attributes such as passenger capacity, luggage volume, comfort level, and vehicle type (e.g., sedan, van). Validate Class Compatibility Collaborate with Hoppa’s team to resolve any ambiguous mappings. Ensure alignment with Hoppa’s regional availability and naming conventions, and validate the mapping logic for uncommon or edge-case vehicle types. Implement in Integration Layer Incorporate the mapping logic into your backend integration layer. Ensure that each quote and booking API request correctly translates your local vehicle class into the corresponding Hoppa-compatible class parameter. Logging & Auditing Log all mapping events, including both successful mappings and exceptions. This facilitates debugging of incorrect bookings, monitoring of mapping-related issues, and effective handling of customer service inquiries. Continuous Review Regularly review and update your vehicle class mappings to account for changes such as: • New vehicles added to your fleet • New vehicle classes introduced by Hoppa • Updates to classification rules or regional shifts in vehicle categorization For more details or clarifications, please reach out to the Hoppa Business Team or feel free to contact the Hoppa Tech Team.
• [Trip Type](https://developers.hoppa.com/enumerations/trip-type.md): One Way A single-direction journey from the pickup location to the drop-off location. No return trip is included. Round Trip A journey that includes both the outbound and return legs. The vehicle wa/its at the destination or returns after a specified duration. Hourly (As Directed) A flexible ride where the vehicle and driver are available for a fixed number of hours. Ideal for multiple stops or events. Pricing is usually time-based Multiday A long-duration booking that spans multiple days, often used for tours, road trips, or business travel with extended itineraries. Shuttle A shared or private service that operates between fixed points (e.g., airport to hotel) on a predefined schedule or on demand. Train Ride A point-to-point intercity or intracity journey via train. This includes booking and managing rail transport along with optional ground pickup and drop-off support. Train Service (Addon/Connection) A complementary ground transport service before or after a train journey, supporting first-mile or last-mile connectivity. Charter A custom, often large-capacity booking (e.g., buses or minibuses) arranged for specific group travel, events, or tours.
• [Postman Collection](https://developers.hoppa.com/sdk-and-tools/postman-collection.md): [https://www.postman.com/elife-partner-rides/elife/collection/em14yhv/elife-partner-rides-multimodal-api-collection](https://www.postman.com/elife-partner-rides/elife/collection/em14yhv/elife-partner-rides-multimodal-api-collection)
• [Widgets and Whitelabels](https://developers.hoppa.com/sdk-and-tools/widgets-and-whitelabels.md): [https://github.com/h5-integrations/whitelabel/wiki/SDK-Integration-Guide](https://github.com/h5-integrations/whitelabel/wiki/SDK-Integration-Guide)
• [Go live Checklist](https://developers.hoppa.com/go-live-checklist.md): * **Integration Certification Guide – Hoppa API** * This guide outlines the certification process required to validate your integration with the Elfe API prior to going live in the production environment. As part of this process, partners are expected to complete a series of structured test scenarios and submit relevant logs for review by the Hoppa technical team. * The objective is to ensure correct handling of bookings, data transmission, disclaimer logic, and voucher generation as per Hoppa’s operational standards. * ✅ Hoppa Partner API – Go-Live Checklist for Integration Partners **1\. Authentication Setup** * Partner has received API Key from Hoppa and validated it in sandbox * API requests use the correct authentication method (e.g., Bearer token). * Token referesh or renewal flow is implemented (if applicable). * Authorization header (\`Authorization: Bearer \`) is included in all requests. * Secure storage of API credentials is ensured (e.g., environment variables). **2**. **Environment Configuration** * Sandbox base URL (\`\`) used for integration testing. * Production base URL (\` ) configured for go-live. * No sandbox keys or URLs exist in the production environment. * Environment variables or configuration toggles are used for environment switching. * Partner confirms separation between test and live booking workflows. **3\. Functional API Testing** * Partner has received API Key from Hoppa and validated it in sandbox. * Partner /ride-quotes\` tested with various parameters including serviceType, time, location, passengers, and luggage. * \`Partner /confirm\` books ride and returns a valid booking ID, with all necessary data. * \`Partner /cancel\` cancels rides and returns valid status response (including policy-driven cases). * \`Partner GET /ride-status\` fetches booking updates in real time with correct statuses. **4\. Additional Services Validation** * Partner has enabled and tested support for Child Seat types (if enabled in their integration scope). * Meet & Greet option is configurable and behaves as expected. * Luggage options (standard/extra) are correctly submitted and affect pricing if applicable. **5\. Vehicle & City Coverage** * Coverage tested with \`GET /coverage\` and cities validated for partner's use case. * All internal vehicle categories mapped to Hoppa’s vehicle codes and names. * Graceful fallback or notification exists for unsupported vehicles or locations. **6\. Pricing, Booking Fee & Commission** * Booking fee retrieved from quote response and displayed correctly to users for train rides. * Price breakdown includes base fare, taxes, fees, and surcharges. * Currency code (e.g., INR, USD) shown properly with formatting rules applied. **7\. Webhooks & Notifications** * Webhook URL registered with Hoppa if real-time notifications are used. * Webhooks tested for all events: Booking confirmed, Driver assigned, Ride started, Ride completed, Cancellation. * Partner systems acknowledge and log incoming webhooks. * Duplicate or retry webhook deliveries handled via idempotency logic. **8\. Date/Time Formatting & Timezones** * All time values sent/received in ISO 8601 format (e.g., \`2025-08-01T14:30:00Z\`). * Partner handles pickup/dropoff in user’s local timezone. * Internal systems convert time correctly for UI and processing flows. **9\. Error Handling & Stability** * Partner handles all Hoppa API response codes (2xx, 4xx, 5xx). * 400-499 errors provide user-friendly responses (e.g., invalid location, unavailable vehicle). * Retry logic in place for temporary issues (e.g., 429 rate limit, 500 server error). * Detailed error logs captured and accessible by developer or support teams. **10\. Logging & Monitoring** * Partner logs all API requests/responses with status, timestamps, and transaction IDs. * API keys, tokens, and sensitive user information are excluded from logs. * Alerts or monitoring dashboards are set up to detect failure spikes or anomalies. **11\. Documentation & Developer Support** * Partner has fully reviewed \[Theneo API Docs\](https://app.theneo.io/hoppa-docs/hoppa-partner-api-multi-modal/about-hoppa-apis). * Internal documentation prepared for tech team reference and troubleshooting. * Escalation contacts and Hoppa support team details are stored securely. **12\. UAT Sign-off** * All critical use cases tested and verified in sandbox: Quote, Book, Cancel, Status. * Edge cases tested: unsupported areas, invalid inputs, cancellation deadlines. * QA team or stakeholder has approved readiness for production. **13\. Final Go-Live Validation** * Production keys configured in secure environment. * Smoke test run in production for real bookings. * Live monitoring confirmed with alerts active. * Final handover or launch confirmation shared with Hoppa support ### Questions? For any certification or integration-related inquiries, contact: