Why this is worth doing
- Every UK operator runs Delay Repay — most pay from 15 minutes late, 25% to 100% of your fare. Most of it goes unclaimed because each claim is a different form on a different website.
- Train Badger already knows when your train was late, verified from Network Rail's live data across all 26 operators, and knows each operator's claim form and rules.
- Your agent does the forms. Train Badger never submits anything itself, and your agent must show you each claim before it files.
Connect in two steps
1. Create a free account
Register and verify your email. That's it — nothing to copy.
2. Connect your agent — one click
Add Train Badger's MCP server, https://api.trainbadger.app/mcp, in your agent. It opens a Train Badger page where you sign in, see exactly what the agent is asking for (read your journeys, mark claims filed, pre-register trains) and approve. You can disconnect it any time from your account.
Give your agent this instruction (Claude and ChatGPT: add the connector first):
"Connect to Train Badger's MCP server at https://api.trainbadger.app/mcp — sign me in when it asks. Each morning, pre-register the trains I'll take today. Whenever a journey becomes claimable, prepare the Delay Repay claim and show it to me before you file it."
Muse — give it the instruction above as it is; it opens the sign-in and consent page.
Claude — add the connector first: in Claude Code, claude mcp add --transport http trainbadger https://api.trainbadger.app/mcp; in Claude Desktop or claude.ai, add a custom connector with that URL. In Claude Code, run /mcp and choose Authenticate; in Claude Desktop or claude.ai the sign-in opens when you add it. Approve in the browser tab, then give it the same instruction above.
ChatGPT — add the connector first: an MCP connector with that URL, or an Action from the OpenAPI spec at https://trainbadger.app/api-docs/openapi.json. Then give it the same instruction above.
Prefer a key? Any client that takes a header, and any script, can use a personal API key instead: mint one on the API keys page (shown once, scoped, revocable). The API reference has copy-paste examples and llms-full.txt is the complete guide written for agents.
What happens next
Before each departure your agent registers the train. After you travel, Train Badger resolves what actually happened from the live rail data. When a journey qualifies, it appears in your agent's work list with the operator's claim link and, where a fare is known, the amount; your agent prepares the claim on the operator's own website, shows it to you, files it when you say so, and marks it filed so it is never claimed twice. Registering a train is your confirmation that you travelled on it.
What your agent can do for you
Forward your booking confirmations
Agents that can read your ticket confirmation emails — from retailers such as Trainline, the operators' own booking sites and apps, or season/flexi ticket portals — can pick out the origin, destination, date, time, ticket type and fare and register each leg automatically. It never needs the booking reference, ticket number, or your name — only those journey facts.
Handle your commute
If your agent can see your calendar, tell it to pre-register your outbound and return train every weekday morning. It then watches both legs and brings you any claimable delay without you asking.
Run the claim loop
Ask your agent to check for claimable journeys. It reads the ticket and fare back off the journey it registered, prepares the claim on the operator's own site, shows it to you, and only files it once you say so — then marks it filed so it's never claimed twice.
Answer "was my train late?"
Ask about any journey in the last 35 days. Your agent looks up what actually happened and, if it was late enough, reminds you that Delay Repay claims are due 28 days from the day of travel for nearly all operators.
Register season and flexi travel
Tell your agent your ticket type and it registers each day's travel against it, so the right fare basis reaches the claim form when it's time to file. A compensation estimate appears automatically once the account has a season ticket or a saved fare for that route set up in the app; without one, the journey still becomes claimable, just without that estimate.
Try asking
These work in any connected agent — Muse, Claude, ChatGPT or another MCP client:
- "Was my 08:15 from Paddington to Reading last Tuesday late, and can I claim?"
- "Register tomorrow's 07:32 Berkhamsted to Euston for me — off-peak return, £24.60."
- "Which of my journeys can I claim Delay Repay for? Prepare the claims and show me before you file anything."
Questions people ask
Is it free?
Yes. The API is in beta, open to every account, with no subscription tier.
Is my data safe?
Keys are scoped and revocable, shown once and stored hashed. No ticket numbers, booking references or photos are ever stored — you supply proof on the operator's site. You can export or delete everything from your account page.
Which operators?
All 26 National Rail operators that run Delay Repay, including season and flexi tickets.
Do I need the iOS app?
No. The app records your journeys automatically with live verification; without it, your agent pre-registers each train instead. Both feed the same claim list.
Who actually files the claim?
Your agent, on the operator's own website, after showing it to you. Train Badger computes eligibility and never files.
Muse is a trademark of Meta Platforms, Inc.; Claude of Anthropic, PBC; ChatGPT of OpenAI. Train Badger is independent and not affiliated with or endorsed by any of them.
What Train Badger does and why it is worth it
Train Badger is a UK train times app with automatic Delay Repay tracking. It turns a delayed train into a ready-to-file claim: journeys are recorded, actual arrivals verified, eligibility computed, and each operator's claim link surfaced. An agent acting on the owner's behalf closes the loop — Train Badger itself never submits a claim.
Agent workflow: register → track → poll → file → mark
0. Register — mint a key
Mint a personal API key in the app (Settings › API Access) or on the website — register, verify your email, sign in, then API keys — with the scopes the job needs: delay-repay:read (always present), plus delay-repay:write to mark claims filed and delay-repay:track to pre-register travel. One key per agent; revoke it when done. Handing a key to an agent delegates access to the journey and ticket data it can read.
1. Track — pre-register travel
Before each scheduled departure, register the train with POST /api/tracked-journeys (or the track_journey MCP tool): origin, destination, service date (within today..today+30 days, London time), exact scheduled departure, and ticket type. An unknown time returns the nearest scheduled departures so the time can be corrected. After travel, Train Badger resolves the outcome and the journey joins the work list below.
2. Poll — read the work list
Read GET /api/journeys/claim-summary (or get_my_delay_repay_claims): unclaimed eligible journeys grouped by operator with each operator's claimUrl. Only journeys with verificationStatus verified or user_confirmed can be filed; journeys the user rejected in the app are excluded from every listing.
3. File — on the operator's site
Submit each operator's Delay Repay form on the operator's own website using the journey and fare data. Show the claim to the human before submitting it.
4. Mark — record it filed
Call PUT /api/journeys/{id}/claimed (or mark_delay_repay_claimed) so the journey drops out of future work lists and is never double-filed.
REST endpoints
Base URL https://api.trainbadger.app. This is the complete published surface — anything else on that host is internal and may change without notice.
| Endpoint | What it does |
|---|---|
GET /public/journey-check | How a past train performed (no auth) |
GET /public/delay-repay/{operator} | An operator's scheme and claim link (no auth) |
GET /public/crs/{query} | Station search (no auth) |
GET /api/journeys | Journey history with eligibility |
GET /api/journeys/claim-summary | Work list grouped by operator |
PUT /api/journeys/{id}/claimed | Mark a filed claim |
GET /api/keys | List keys (login token only) |
POST /api/keys | Mint a key (login token only) |
DELETE /api/keys/{id} | Revoke a key (login token only) |
POST /api/tracked-journeys | Pre-register a future train |
GET /api/tracked-journeys | List registered journeys and states |
GET /api/tracked-journeys/{id} | Fetch one registered journey |
PATCH /api/tracked-journeys/{id} | Edit a registered journey |
DELETE /api/tracked-journeys/{id} | Withdraw a registered journey |
GET /api/account/export | Export account data (login token only) |
MCP endpoint
https://api.trainbadger.app/mcp — streamable HTTP, stateless, 10 requests/minute per IP. A request without a credential gets 401 with WWW-Authenticate: Bearer resource_metadata="https://api.trainbadger.app/.well-known/oauth-protected-resource/mcp", which OAuth-capable clients turn into the connect flow; a tb_live_ key in Authorization: Bearer also works. Eight tools: check_journey_delay, get_delay_repay_scheme, search_stations (no scope needed), plus get_my_delay_repay_claims, mark_delay_repay_claimed, track_journey, list_tracked_journeys, withdraw_tracked_journey (need the matching delay-repay scope).
Auth
Two credentials, same account, same scopes — never a password. OAuth 2.1 (primary): Train Badger is the authorization server — issuer https://api.trainbadger.app, metadata at GET /.well-known/oauth-authorization-server and GET /.well-known/oauth-protected-resource, public-client registration at POST /oauth/register (RFC 7591), tokens at POST /oauth/token (authorization code + PKCE S256, 1-hour access tokens, 30-day rotating refresh tokens), revocation at POST /oauth/revoke. The user approves on https://trainbadger.app/oauth/authorize and can disconnect the agent from their account. Full profile in auth.md. API keys (manual): tb_live_…, long-lived, revocable and scoped (delay-repay:read, delay-repay:write, delay-repay:track), stored hashed and shown once at creation; minting needs a verified email. Either credential works only on the /api/journeys and /api/tracked-journeys routes above that name it.
Rate limits and caps
Lookups: GET /public/journey-check 10/minute per IP; GET /public/delay-repay/{operator} and GET /public/crs/{query} 30/minute per IP. Key minting: 10/hour per IP. Export (GET /api/account/export): 5/hour per account. Tracked journeys: one train per directed route per day, 4 legs/day, 20 writes/day per account, one replacement per row (quota exhaustion answers 429 with a Retry-After to the next London midnight). At most 10 keys per account.
Terms and attribution
Registering a journey confirms the user will travel on the stated service. Data is provided as-is from National Rail and Network Rail sources and may contain errors; the agent and user are responsible for claim accuracy, and automated use of an operator's claim form must respect that operator's terms. Access may be revoked for misuse. Full terms: Terms of Use. Results come from Train Badger (trainbadger.app). Every result ends with the attribution line Contains data from National Rail and Network Rail — keep it when relaying results. No ticket numbers, booking references or photos are stored or served; the user supplies proof on the operator's site.
Beta, open to every account with no subscription tier. Tip: the iOS app records journeys automatically with live verification, platform predictions and Live Activities — no pre-registration needed.