Bus Booking API Frequently Asked Questions

Incoming Margin is the commission or margin that eTravelSmart receives from the respective bus operator for a booking. An API partner receives the agreed percentage of this incoming margin based on the applicable partner commercial plan.

Example:
If the operator commission is 10% on a Rs.1,000 base fare:
- eTravelSmart incoming margin = Rs.100
- Under an 80% revenue-share plan
- Partner share = Rs.80
- eTravelSmart share = Rs.20

The current operator-wise commission information is available on the eTravelSmart page: Operator Commission / Discounts. The operator commission may vary by operator, while the partner's agreed revenue-share percentage remains fixed according to the selected commercial plan.

Yes. The agreed partner revenue-share percentage remains applicable according to the selected plan. However, the underlying operator commission can vary by operator and inventory source, so the actual commission amount can differ from one operator to another.

Yes. The underlying operator commission can vary depending on the operator and inventory source. The partner receives the agreed share of the actual incoming margin applicable to the booking.

Commission is calculated on the applicable base fare/incoming margin, excluding the operator's GST or other tax components. The exact tax and settlement treatment is subject to the applicable commercial agreement and statutory requirements.

For example:
- Base fare: Rs.1,000
- Operator GST: Rs.50
- Operator commission: 10%
- Incoming margin: Rs.100
- Partner share under 80% plan: Rs.80

The revenue-share plans primarily determine the partner's share of the incoming margin. The standard API access, bus inventory, operator coverage, booking functionality, cancellation functionality and technical support remain the same under the standard API partnership model.

There is no separate API feature set or inventory restriction based solely on the selected revenue-share percentage.

The availability of particular operators, RTC inventory and specific booking features may depend on the respective operator, inventory source and applicable operator terms.

Yes. The selected revenue-share percentage is applicable according to the agreed commercial plan and Partner Agreement. Any subsequent change to the agreed plan or revenue-share percentage would be subject to mutual discussion and agreement.

Yes. The applicable commission and tax treatment are handled according to the agreed commercial arrangement and prevailing statutory requirements. Partners should account for GST according to their applicable GST registration and tax obligations.

The partner is required to raise the applicable invoice to eTravelSmart and account for GST on the commission according to applicable GST requirements.

For example, if the gross commission is Rs.80, the GST component included in that amount at 18% is approximately Rs.12.20. (Rs.80*18/118)

The exact tax treatment should be handled according to the partner's GST registration and applicable statutory requirements.

Under the standard commercial structure, the applicable one-time onboarding fee is the primary requirement for selecting the corresponding revenue-share plan. There are no standard monthly or annual charges, minimum booking commitments or separate API transaction charges. Any specific commercial commitment or special condition, if mutually agreed for a particular partnership, would be documented separately in the Partner Agreement.

Yes. Applicable TDS is deducted from partner commission and deposited against the partner's PAN, as required. The applicable tax credit can be reflected in Form 26AS and Form 16 can be provided where applicable. As per the current settlement process, 2% TDS is deducted from the applicable commission amount.

Commission settlement happens automatically with each booking. The applicable commission is adjusted as part of the booking transaction, and the net payable amount is deducted from the partner's prepaid wallet.

There are no discounts for the partners. The partner share is based on the applicable operator incoming margin for the booking. The treatment of cancellation charges, refunds, penalties, payment gateway charges, or other adjustments depends on the transaction and applicable settlement rules of the booked bus operator and as applicable.

Where there is no applicable incoming margin, there may be no commission available for revenue sharing. Specific treatment of exceptional or negative-margin transactions is governed by the applicable commercial arrangement.

There are no standard monthly or annual recurring charges under the standard API model. Any customized service or additional arrangement, if applicable, will be communicated separately.

Standard commercial plans are available. Strategic or high-volume partners may discuss customized commercial arrangements based on business potential, expected volumes and mutually agreed terms.

Agreed commercial terms remain applicable according to the Partner Agreement. Any change should be mutually discussed and formally documented.

No. The onboarding/integration fee is a one-time, non-refundable fee and is not credited to the booking wallet.

The onboarding fee is non-refundable. The exact obligations of both parties regarding integration and activation are governed by the Partner Agreement.

There are no standard minimum booking commitments in the normal API model. Any specific commitment agreed for a particular partnership will be documented separately.

There is no standard exclusivity requirement in the normal API model. Any specific exclusivity arrangement would need to be mutually agreed and documented.

No. There are no standard annual renewal or monthly maintenance charges under the standard API model.

Yes. eTravelSmart uses a prepaid wallet model for API bookings. The applicable net booking amount is deducted from the partner wallet during the booking transaction.

The standard minimum wallet top-up is communicated during onboarding and is subject to the prevailing wallet policy.

Wallet funding is separate from the non-refundable onboarding fee. Withdrawal or refund conditions for unused wallet funds are governed by the applicable wallet and termination policy.

The treatment of unused wallet funds after termination is governed by the applicable wallet and termination provisions of the Partner Agreement. However we recommend you to utilize the wallet amount against the bookings only.

There are no standard monthly wallet maintenance or annual wallet charges. Any expiry, withdrawal or termination-related conditions are governed by the applicable wallet policy and agreement.

Wallets can be recharged through the payment methods enabled for the partner, including applicable bank-transfer and payment-gateway options.

- NEFT/IMPS - payment is made to the designated bank account and reported through the Partner Portal.
- Instant payment gateway recharge, where enabled.

For instant recharge, applicable payment gateway 2% charges may apply.

Wallet transactions are maintained in INR. International payment arrangements can be evaluated separately based on the partner's legal entity, banking arrangements, applicable tax requirements and payment method.

There is currently no standard API-based automatic wallet recharge facility. For high-volume partners, automated wallet funding can be evaluated separately based on technical feasibility and mutually agreed arrangements.

Bank-transfer recharges are credited after the amount is received and verified. Payment-gateway recharges, where enabled, are generally credited after successful payment processing immediately.

Wallet balance alerts can be provided through the Partner Portal and configured notification process. Partners should maintain adequate balance based on expected booking volume. Email alerts are generated when the wallet balance falls below the configured threshold.

There is no standard maximum wallet balance or fixed daily booking limit specified for API partners. Operational controls may be applied based on traffic, risk management, operator requirements or mutually agreed arrangements.

A booking cannot be completed if sufficient wallet balance is not available. Partners should maintain adequate balance based on expected booking volumes.

Yes. Wallet and transaction information is available through the Partner Portal, including relevant wallet transactions, booking deductions, refunds and adjustments.

Commission is adjusted as part of the booking transaction. The partner's applicable commission is accounted for and the net amount is charged to the prepaid wallet.

Yes. API partners can use their own payment gateway to collect the customer payment.

Yes. The partner collects the customer payment through its own payment gateway and uses its prepaid eTravelSmart wallet balance to complete the booking.

The applicable partner commission is adjusted automatically during the booking transaction. The wallet is charged only for the net payable amount after applying the partner's applicable commission, along with applicable operator taxes and charges.

No. The partner's commission is not separately settled to a bank account under the standard API model. It is adjusted directly in the wallet at the time of booking.

No standard wallet withdrawal or settlement charges are applicable under the standard API model. The partner's commission is adjusted directly against the booking amount.

If a booking fails after an amount has been deducted, the transaction is checked and the applicable amount is reversed or refunded after verification. The exact treatment depends on the booking status received from the operator or eTravelSmart system.

eTravelSmart provides the API platform and booking infrastructure and supports partners in resolving booking-related technical issues. Where a failure originates from an operator, payment gateway, network or other external system, the transaction is investigated and resolved based on the actual status.

Duplicate or suspected duplicate transactions are investigated using booking and operator transaction references. The appropriate action is determined based on the actual booking status. Partners should also implement safeguards against duplicate API requests.

The API partner generally manages the customer-facing booking experience and communication, while eTravelSmart provides the booking and cancellation functionality and supports transaction-related issues, unless otherwise agreed.

For successful cancellations, the applicable refund is generally processed in real time or immediately after successful cancellation, subject to the operator's response and transaction processing.

Operator cancellation charges are applied according to the applicable operator cancellation policy. The customer refund is calculated after applying the applicable cancellation charges.

This depends on the nature of the incident and the operator's terms and conditions. Compensation beyond the applicable operator refund should not be assumed unless specifically provided under the operator policy or separately agreed.

Rescheduling availability depends on the operator and applicable booking rules. Where an operator supports rescheduling, the applicable process and charges will apply.

Yes. Depending on the operator and service, e-tickets can be delivered through supported channels such as PDF, SMS and WhatsApp.

Yes. API partners can collect customer payments through their own payment gateway.

Yes. Partners can add their own customer-facing markup or service charge. However, the actual bus fare supplied by eTravelSmart or the operator cannot be altered.

Payment gateway charges associated with the partner's own customer payment gateway are generally the partner's responsibility. Charges applicable to eTravelSmart wallet recharge through a payment gateway are handled according to that payment method.

Customer payment gateway chargebacks, fraud-related losses or disputes arising from the partner's own payment collection generally remain with the partner, subject to the payment gateway terms. Operator/eTravelSmart-side transaction disputes are handled based on the actual transaction and applicable agreement.

Yes. We can arrange a walkthrough/demo of the bus booking flow. Partners can also review the live eTravelSmart bus booking platform and, where appropriate, existing integrated client applications to understand the search, seat selection, booking and customer experience.

eTravelSmart provides a RESTful JSON Bus Booking API that can be integrated with any technology capable of consuming REST APIs.

The API uses secure authentication for partner access. The exact authentication parameters and implementation details are provided in the API documentation.

Yes. Complete API documentation is available at eTravelSmart Bus API Documentation.

Yes. Sandbox or testing credentials are provided as part of the formal onboarding and integration process.

A standard free trial API is not provided. Partners can review the API documentation before proceeding, and sandbox access is provided as part of the formal onboarding process.

Sandbox credentials can generally be provided promptly after the required onboarding formalities are completed, subject to the applicable onboarding process.

The integration timeline depends on the partner's technology stack, development resources, testing requirements and scope. Once sandbox access is provided, the technical team can begin integration.

Fares and seat availability are retrieved from applicable live inventory or operator systems as part of the search and booking flow. Final fare and seat availability should be validated during the applicable booking or seat-blocking process.

Some operators dynamically change fares, taxes or other charges after seat selection or blocking. If such a change is returned during the blocking process, the updated fare is shown to the customer before payment. The partner application should handle the updated fare response.

The partner should not immediately repeat a booking request without first checking the transaction or booking status, because repeating a booking request could potentially create a duplicate transaction.

The API returns response information for successful and unsuccessful requests. Partners should implement error handling according to the API documentation and should verify booking status before treating a timeout or technical error as a failed booking.

Traffic controls may be applied based on the partner's usage pattern, including search-to-booking ratio and production traffic. Applicable limits are determined based on operational requirements.

eTravelSmart operates production API infrastructure designed for reliable and scalable bus booking. Specific contractual uptime, response-time commitments and SLA metrics should be referred to in the applicable support or SLA agreement.

Yes. Sample API requests and responses are available in the API documentation and can be provided to the technical team during the integration process.

A Postman collection is not part of the standard API documentation currently. However, a Postman collection can be provided where required to assist the partner's development and testing.

Yes. If there are changes to the API that affect integration, the relevant API documentation will be updated and communicated to partners.

API response time depends on several factors, including the underlying operator's response time, traffic, network conditions and peak or non-peak periods.

eTravelSmart works to maintain API responses within approximately 3-5 seconds under normal operating conditions, wherever the underlying operator response permits.

The current production infrastructure targets approximately 99.8% API availability.

eTravelSmart has monitoring and recovery mechanisms in place to minimize service disruption and restore services as quickly as possible.

The applicable recovery target and any formal SLA commitments are subject to the agreed support/SLA arrangement.

The customer payment is collected by the partner through its own payment gateway. eTravelSmart deducts the wallet amount only after the booking is successfully completed.

If the customer has been charged but the booking is not successfully completed, the partner should handle the customer refund through the same payment method used for the original payment.

Failed bookings are investigated based on the actual transaction and operator status. Where the booking is confirmed as failed, the applicable wallet amount is reversed/refunded.

For pending transactions, the booking status should first be verified before initiating another booking attempt to avoid duplicate bookings.

No separate API transaction or per-booking service charge is applicable under the standard API commercial model.

Yes. eTravelSmart provides technical support during integration and assists partners with API implementation and troubleshooting. Technical support is available during office hours between 10 am to 7PM in working days.

Support availability and escalation arrangements depend on the applicable support arrangement. In general service support is available from 10 am to 10 pm.

Yes. An account manager can assist with onboarding, commercial coordination and ongoing business support.

Yes. Technical, customer-support and accounting or reporting queries can be routed to the respective eTravelSmart support teams. A formal escalation matrix can be defined for partners where required.

Yes. Partners can access booking, wallet, transaction and relevant settlement information through the Partner Portal. Specific report formats and additional reporting requirements can be discussed during integration.

Relevant reports are available through the Partner Portal. Specific export formats or customized automated reports can be discussed based on the partner's requirements.

Data ownership and processing rights are governed by the Partner Agreement and applicable data-protection requirements. The respective rights and responsibilities of both parties should be defined in the agreement.

Data export and retention arrangements are governed by the termination and data-protection provisions of the Partner Agreement. The export format and retention period can be agreed during contracting.

Customer information may need to be transmitted to relevant bus operators, service providers, payment or technology partners, or other parties necessary to complete and support a booking. Such processing is subject to applicable privacy and data-protection requirements.

eTravelSmart uses secure API access and HTTPS-based communication for production services, along with authentication and controlled access to partner systems. Detailed security and data-protection information can be shared where required.

Responsibility is determined based on the cause of the incident, the systems and responsibilities of each party, applicable law and the contractual data-protection provisions.

Yes. Partners can use their own branding, website or app, customer-facing interface, payment gateway and customer communication channels, subject to agreed integration and branding guidelines.

Yes. A standard Partner Agreement is executed as part of the onboarding process and covers applicable commercial, operational, payment, support and other partnership terms.

The agreement is shared once the commercial terms are finalized and the onboarding process reaches the applicable stage. Contractual queries can be discussed before execution.

The standard contract period should be confirmed in the applicable Partner Agreement. No minimum lock-in period should be assumed unless specifically stated in the executed agreement.

Termination is possible subject to the terms and notice requirements specified in the Partner Agreement.

The treatment of unused wallet balance after termination is governed by the applicable wallet and termination provisions of the agreement. The onboarding fee remains non-refundable.

Any applicable termination charges or obligations are as specified in the signed Partner Agreement.

Any change to agreed commercial terms should be mutually discussed and formally documented.

The applicable dispute-resolution mechanism and governing jurisdiction are specified in the signed Partner Agreement.

For bus booking services operated in India, eTravelSmart may require an appropriate Indian business entity and applicable registrations such as PAN and GST, depending on the nature of the business and prevailing regulations. Exact requirements are confirmed during onboarding.

Wallet transactions are maintained in INR. International payment arrangements can be evaluated separately based on the partner's legal entity, banking arrangements, applicable tax requirements and payment method.

Settlement arrangements depend on the partner's legal structure, applicable tax and regulatory requirements, and agreed commercial terms. These details are confirmed during onboarding.

Depending on the stage of discussion, eTravelSmart can provide or discuss API documentation, commercial information, revenue-share examples, wallet and payment processes, Partner Agreement, support or SLA information, security and data-protection terms, sample booking or settlement reports, and termination or data-export provisions.

Yes. Commercial and contractual terms can be discussed with the eTravelSmart team. The standard agreement is shared once the commercial terms and onboarding process reach the applicable stage.

Yes. Revenue-share calculations can be explained with operator-wise examples based on the applicable incoming margin and selected partner plan.

Yes. The applicable wallet, booking, cancellation, refund and settlement processes can be provided or explained as part of onboarding and contractual documentation.

Yes. The standard support process can be explained, and an appropriate SLA or support matrix can be discussed for partners requiring formal response and resolution commitments.

Yes. Relevant sample reports can be shared during the technical or commercial evaluation process, subject to appropriate confidentiality and data-protection considerations.

Basic company/partner information and applicable KYC documents are required. Depending on the partner type, this may include PAN, GST details where applicable, company incorporation/business information and other required identification or verification documents.

No. The onboarding process and documentation can be handled as part of the onboarding process after the commercial terms are finalized.

The agreement and technical onboarding can be progressed in parallel, subject to completion of the required onboarding formalities.

Sandbox credentials can generally be provided within approximately one working day after completion of the required onboarding formalities and documentation.

eTravelSmart provides extensive bus inventory covering private bus operators across India along with selected RTC/government transport inventory, subject to availability and applicable operator or government rules.

Yes. eTravelSmart has integrations with major bus technology platforms, aggregators and direct operator systems, providing a combination of direct and aggregated inventory.

eTravelSmart uses a combination of direct operator integrations and aggregator/GDS integrations, depending on the operator and inventory source.

Yes. Available operator information and applicable incoming-margin/discount information can be reviewed through the eTravelSmart operator/discount information provided to partners.

Yes. The integration environment can be used to test the relevant booking workflow, including:

Search → Bus Details → Seat Layout → Boarding/Dropping → Fare → Booking → Ticket/M-ticket → Cancellation → Refund

The exact availability of each test scenario depends on the sandbox inventory and supported test cases.

Yes. Where required, selected low-fare services with suitable cancellation conditions can be used for controlled production testing before full-scale go-live, subject to prior coordination with the eTravelSmart team.

No. eTravelSmart does not separately deduct its share of the incoming margin again merely because a ticket is cancelled.

Yes. The commission previously adjusted in favour of the partner is reversed/adjusted as part of the cancellation settlement, along with the applicable refund calculation.

The cancellation is processed through eTravelSmart according to the applicable bus operator's cancellation policy. Once the cancellation is successfully completed, the applicable refund amount is credited to the partner's eTravelSmart wallet.

The partner can then refund the customer through the same payment method used to collect the original payment.

No standard additional eTravelSmart cancellation or refund processing fee is charged.

However, the bus operator's applicable cancellation charges will be deducted according to the operator's cancellation policy.

Cancellation rules are primarily determined by the respective bus operator. The applicable operator cancellation policy is provided as part of the booking information and should be displayed to the customer before booking.

No. The API partner is responsible for sending the booking confirmation, ticket and customer notifications under its own brand.

This allows the partner to maintain its own customer relationship and branding.

Yes. The required customer and booking information is available to the partner during the booking process, allowing the partner to manage its own customer communication.

Yes. Partners can use their own communication infrastructure to send booking confirmations, tickets and other notifications through email, SMS and WhatsApp, as applicable.

In some cases, the bus operator may also independently send notifications to the customer.

eTravelSmart does not provide these customer notification services as part of the standard API booking flow and therefore does not charge the partner for such notifications.

Under the standard API model, there are no monthly or annual recurring charges. The applicable commercial structure consists of the agreed onboarding fee, applicable GST, revenue-share arrangement and actual payment-related charges where applicable.

The typical process is:

Commercial Discussion → Commercial Finalization → Onboarding → Agreement → Sandbox Access → Integration → Testing → Production Credentials → Go-Live.

eTravelSmart combines more than a decade of online bus-ticketing experience, a broad operator and route network, 200+ API integrations, RESTful JSON APIs, a scalable booking platform, competitive partner programs, and dedicated technical and account support. Our objective is to provide a long-term technology and distribution platform that helps partners grow their bus-booking business.

The document uses a hypothetical Rs.1,000 ticket fare under a 60% revenue-share plan. The figures are for illustration only; actual operator fares, GST, cancellation charges, taxes and incoming margins may vary by operator, route and booking.

For a Rs.1,000 published base fare and a 10% eTravelSmart incoming margin, the incoming margin is Rs.100. Under a 60% partner revenue-share plan, the partner share is Rs.60 and eTravelSmart's share is Rs.40.

The example assumes Rs.1,000 fare, Rs.60 partner commission and illustrative operator GST of Rs.50. Therefore, the partner wallet deduction is Rs.1,000 − Rs.60 + Rs.50 = Rs.990.

Yes. In the example, the partner adds a Rs.50 customer-facing service charge/markup, so the customer pays Rs.1,050. The partner's markup is independent of the eTravelSmart incoming-margin calculation.

For the Rs.60 gross partner commission, the example treats GST as inclusive at 18%. GST is calculated as Rs.60 × 18 / 118 = approximately Rs.9.15, leaving Rs.50.85 commission excluding GST.

The example assumes TDS at 2% on the commission amount excluding GST. Rs.50.85 × 2% = approximately Rs.1.02, resulting in net commission after TDS of approximately Rs.49.83.

The example assumes a 20% operator cancellation charge on a Rs.1,000 fare. The illustrative customer refund is therefore Rs.800. The actual cancellation amount depends entirely on the applicable operator policy, cancellation time and ticket conditions.

The original Rs.60 partner commission is reversed/adjusted as part of the cancellation settlement. The partner does not retain the original commission on a cancelled booking.

No. eTravelSmart does not separately deduct its 40% share of the original incoming margin again merely because the ticket is cancelled. The cancellation settlement is based on the actual operator cancellation/refund calculation and the reversal of the applicable partner commission.

Once the ticket is successfully cancelled through eTravelSmart, the applicable refund amount is credited to the partner's eTravelSmart wallet. The partner can then refund the customer through its own payment gateway. The document states that the refund is generally processed immediately after successful cancellation, subject to successful operator confirmation.

The normal booking journey can be understood as:

Search → Bus Details → Seat Layout → Boarding / Dropping Point → Fare Validation → Seat Blocking / Booking → Payment through Partner's Payment Gateway → Booking Confirmation → Ticket / M-Ticket → Customer Notification → Cancellation, if requested → Refund Calculation as per Operator Policy → Refund/Credit to Partner Wallet → Partner Refunds Customer.

The partner can collect the customer payment through its own payment gateway.

eTravelSmart bookings operate through the partner's prepaid wallet.

The partner receives the agreed percentage of eTravelSmart's actual incoming margin.

The partner may add its own permissible markup/service charge to the customer-facing price.

The actual bus fare supplied by the operator/eTravelSmart should not be altered.

GST, TDS and other statutory obligations are handled according to the applicable tax rules and the partner's tax status.

Cancellation charges and refund amounts are determined by the respective bus operator's cancellation policy.

Partner commission applicable to a cancelled booking is reversed/adjusted.

After successful cancellation, the applicable refund is credited to the partner's eTravelSmart wallet. The partner handles the customer refund.

Partners should verify booking status before retrying a request, particularly after a timeout, to avoid duplicate bookings.

Partners are responsible for customer-facing email, SMS and WhatsApp communication under their own brand.

No. The fare, operator margin, GST, cancellation charges and other amounts in the example are illustrative. Actual values are determined by the operator and transaction.