Indian Railway IRCTC API: Train Search & Live Status

What the API does and who it is for

The Indian Railway IRCTC API consolidates several categories of Indian Railways information behind a uniform HTTP interface. Because Indian Railways has no widely accessible public API of its own, third-party services like this one fill a genuine gap for developers building travel assistants, PNR trackers, trip planners, or any product where Indian rail data plays a role.

The provider is explicit that this is an unofficial service with no affiliation to Indian Railways, IRCTC, or CRIS. All data originates from publicly available sources and third-party providers. That disclaimer is important: data freshness and accuracy depend on upstream sources, not on any direct feed from the railway operator. With an average success rate of 94% and an average latency of 806 ms, the API is generally reliable but not suitable for hard real-time systems where sub-second guaranteed responses are a requirement.

Endpoint walkthrough

The API exposes 11 GET endpoints, which fall into a handful of functional groups.

Train discovery

• GET /api/trains-search/v1/train/{trainnameOrnumber} — The primary search endpoint. Supply either a train number or a partial name and receive detailed information about matching trains, including the internal train id that several other endpoints require.
• GET /services/train/{trainNumber} — Returns basic train details by number. Useful for quick lookups when you already have the number and only need core metadata.
• GET /services/getTrains and GET /trains — Both return broad train lists, intended for autocomplete/suggestion UX. The distinction between the two is not documented, so it is worth testing both against your use case.

Schedule and running days

• GET /v2/other-services/running-days/{trainNumber} — Returns the days of the week on which a given train operates. This endpoint appears twice in the endpoint list, suggesting it may be a versioned duplicate.

Live status and running position

• GET /api/trains/v1/train/status — The primary live status endpoint. Requires train_number and departure_date (formatted as YYYYMMDD) as query parameters. Returns current position, departure and arrival times, and delay information.
• GET /v2/other-services/running-status/{trainNumber} — An alternative running status endpoint that accepts a date. Like the running-days endpoint, it appears twice in the list.
• GET /services/get-ntes-running-status/{trainnumber} — A separate live status source, likely pulling from India's National Train Enquiry System (NTES). Worth testing alongside the primary status endpoint to compare data freshness.

Fares

• GET /services/fare — A fare calculator. The documentation does not detail which query parameters it accepts (origin, destination, class, quota), so inspect the response schema after authentication to understand the full parameter set.

Authentication

All requests are authenticated via RapidAPI. Add x-rapidapi-key (your RapidAPI key) and x-rapidapi-host (indian-railway-irctc.p.rapidapi.com) to every request header. The x-rapid-api: rapid-api-database header is also required based on the documented examples.

Pricing breakdown

The API uses a freemium model with four tiers.

The BASIC tier's 50 requests per month is extremely limited — roughly one or two train lookups per day. It is adequate only for initial exploration and testing, not for any live product. The PRO tier at $3.69/month unlocks 1,000 daily requests, which is sufficient for small consumer apps or internal tooling with moderate traffic. ULTRA's overage pricing ($0.005 per request) makes it predictable for applications with variable or spiky load. MEGA's flat 10,000 daily cap with no stated overage is the most straightforward option for high-volume production systems.

Practical use cases

Commuter apps: Combining the train search and live status endpoints lets you build a simple dashboard where users enter a train number and see whether their service is running on time.

Trip planners: The running-days endpoint allows filtering out trains that do not operate on a traveler's chosen date, reducing irrelevant results before surfacing ticket links.

Fare estimation: The fare calculator endpoint can feed price estimates into a trip budget tool, though you should validate parameter semantics before relying on it in production.

Autocomplete and search UX: The /services/getTrains and /trains endpoints provide bulk train data that can be indexed client-side to power instant suggestions without an API call per keystroke.

Limitations and things to verify before integrating

Unofficial data source. Because this is not a direct feed from Indian Railways or IRCTC, there is an inherent risk of data lag or inaccuracies, particularly for live status during disruptions. Cross-check responses against the official NTES portal during your testing phase.

94% success rate. A 6% failure rate across all calls is something to plan for explicitly. Implement retries with exponential backoff, and design your UI to degrade gracefully rather than showing empty states or crashes.

806 ms average latency. For synchronous UI flows, this is perceptible. Consider loading states or skeleton screens, and evaluate whether caching schedule data (which changes infrequently) can reduce live call volume.

Duplicate endpoints. The running-days and running-status endpoints each appear twice in the endpoint list. Before building, confirm which URL paths are active and whether both return identical data.

Fare endpoint parameters. The documentation does not specify required query parameters for /services/fare. Use a tool like the RapidAPI console to inspect the schema before coding against it.

BASIC tier is test-only. With only 50 monthly requests, the free tier cannot support anything beyond exploration. Budget for at least the PRO tier from the outset of any real project.

Getting started

1. Subscribe to the API on RapidAPI and obtain your x-rapidapi-key.
2. Start with the train search endpoint: GET /api/trains-search/v1/train/{trainnameOrnumber} using a known train number such as 12051. Note the internal train id returned — you will need it for live status calls on some endpoints.
3. Call GET /api/trains/v1/train/status with train_number and today's departure_date (e.g., 20240623) to verify live status is returning current data.
4. Test the fare endpoint and running-days endpoint to understand their parameter requirements before wiring them into your application.
5. Instrument your integration to track error rates. If you observe success rates below the documented 94% average, add a retry layer before escalating to the provider.