IRCTC API integration: adding train booking to your travel portal

What IRCTC is and why rail matters for Indian portals

IRCTC (Indian Railway Catering and Tourism Corporation) is the public-sector company that runs online ticketing for Indian Railways. For a domestic Indian travel portal, rail is not a nice-to-have: trains carry far more passengers in India than airlines do, and an agent desk that can quote a flight but not a train sends customers elsewhere. Adding a rail module to a B2B travel portal or agency system keeps that business, and the service-charge income that comes with it, inside your platform.

The access model: regulated, and worth respecting

This is the part of the page to read most carefully. IRCTC does not hand out open booking APIs the way a bed bank or a bus aggregator does. Reserved e-ticketing for agents runs through IRCTC-authorised principal service providers (PSPs): companies appointed by IRCTC that enrol sub-agents, issue agent IDs and provide the sanctioned booking channels under IRCTC's rules for e-ticketing service providers. Agents are expected to book only through IRCTC-provided agent identities, and the rules cover conduct, charges and misuse.

In practice, that means three things for a portal owner:

• Your agency obtains agent access through an IRCTC-authorised principal or aggregator programme, on that programme's commercial terms [TO CONFIRM: the specific programme and scheme your business qualifies for]
• Any API-level connectivity your portal uses must come from that authorised channel, with its permissions and restrictions intact
• Workarounds such as screen scraping, unauthorised automation or shared personal accounts are off the table; they breach IRCTC rules and put your agency codes at risk

We advise on the technical side only. We do not provide, resell or arrange IRCTC access, and we will decline builds that try to route around the authorised model. What we will do is help you ask the right technical questions of a prospective principal provider before you sign: what endpoints are exposed, what booking classes and quotas are covered, and how settlement and cancellation flows work.

What we build once access is in place

With legitimate credentials from your authorised channel, we develop the rail module inside your portal:

• Train search and availability: trains between stations by date, with classes, quotas and fare display as exposed by your provider's API
• PNR and booking status: status lookup and booking records synchronised into your admin panel
• Agent booking workflow: passenger forms tuned for rail (berth preferences, ID requirements, senior and child rules as applicable), quote-to-book handoff and printing or sharing of e-tickets per your provider's rules
• Service charges and accounting: your permitted agent service charge applied transparently, ledger entries per booking, and end-of-day reconciliation against the provider statement
• Cancellations: cancellation requests routed through the sanctioned flow with refund tracking in your back office

Where a provider exposes only a hosted booking window rather than a full API, we integrate at the level that is actually permitted: launch-in-context with agent identity, plus booking record import for accounting. It is less glamorous than a native flow, but it is compliant, and it still saves your agents from juggling systems.

How rail fits the rest of your platform

Rail rarely stands alone. The common build is a multi-product agent desk: flights through your consolidator or GDS, buses through an aggregator (see bus API integration), hotels, and rail, all sharing one customer record, one wallet or credit ledger and one accounting layer inside your travel agency software. Because rail bookings in India are high-frequency and low-margin, the workflow has to be fast: saved passenger lists, prefilled forms and keyboard-friendly screens matter more here than on any other product.

Honest constraints to plan around

A few realities shape every rail project, and we would rather state them up front than surprise you in week three. Peak-time booking (including tatkal windows) is subject to IRCTC's own controls and provider-side restrictions, and no portal feature can promise confirmed seats. Access terms, permitted charges and programme rules are set by IRCTC and its authorised providers and can change; your module has to be built to tolerate that. And approval timelines for agent enrolment sit with the provider, not with us, so we sequence development to start on the parts that do not depend on credentials while your enrolment is in progress.

Process and timeline factors

1. 01

   Access review

   We look at what your authorised provider actually exposes: API scope, documentation, test environment and restrictions. If you have not chosen a provider, we help you evaluate the technical side of candidates.

2. 02

   Module design

   Rail search and booking screens designed for agent speed, plus the accounting and reconciliation flows agreed with your operations team.

3. 03

   Build and test

   Development against the provider's test facilities where offered, with careful handling of live-environment testing rules where not.

4. 04

   Launch and handover

   Staged rollout to a small agent group, monitoring, then full rollout with documentation for your team.

Timeline depends mainly on your provider's API maturity and how much of the surrounding portal already exists. We quote fixed prices per scope, and rail modules are usually delivered as part of a wider travel API integration or portal project rather than in isolation.

IRCTC is a trademark of Indian Railway Catering and Tourism Corporation Ltd. Globitude Travels & Tech is an independent software developer. We are not affiliated with, endorsed by or acting for IRCTC, Indian Railways or any principal service provider, and we do not provide or arrange ticketing access. We build software for agencies that hold their own authorised access.