Transport for London API Getting Started: Account & First Request

Getting started overview

Integrating with the Transport for London (TfL) API allows developers to access a range of public transport data for London, including live line status updates, journey planning tools, and disruption information. The process for getting started involves creating a developer account, obtaining API keys, and then making authenticated requests to the API endpoints. This guide provides a structured approach to complete these initial steps and execute your first successful API call.

The TfL API is designed to support applications that require dynamic access to transport data, such as real-time passenger information systems, journey planners, and data analytics platforms focused on urban mobility. Standard access to the API is free upon registration, with options for higher volume usage potentially requiring direct contact with TfL. The API's comprehensive documentation includes details on various endpoints and data formats, primarily JSON. Before making any requests, it is essential to understand the authentication mechanism, which relies on an App ID and App Key.

Quick Reference: Getting Started Steps

Create an account and get keys

Accessing the Transport for London API requires a developer account and associated API keys. These keys, consisting of an App ID and App Key, authenticate your requests and ensure proper usage tracking.

1. Navigate to the TfL API Portal: Open your web browser and go to the official TfL API account creation page. This is the central hub for developers to manage their API access.
2. Register for a New Account: Look for a "Register" or "Sign Up" option. You will typically need to provide an email address, create a password, and agree to the terms and conditions. Ensure you use a valid email address as it will be used for verification and communication regarding your API access.
3. Verify Your Email: After submitting your registration, check your email inbox for a verification link from TfL. Click this link to activate your developer account. Without verification, you may not be able to proceed.
4. Log In to Your Dashboard: Once your account is verified, log in to the TfL API developer dashboard using your newly created credentials.
5. Generate API Keys: Within your dashboard, locate a section typically labeled "My Apps" or "API Keys." You will need to create a new application entry. When creating an application, the system will automatically generate an App ID and an App Key for you. These are your unique credentials.
   • App ID: A unique identifier for your application.
   • App Key: A secret key used to authenticate your application. Treat this key as sensitive information and do not expose it in client-side code or public repositories.
6. Record Your Keys: Copy and securely store both your App ID and App Key. You will need these for every API request you make. If you lose your App Key, you may need to regenerate it from your dashboard, which could invalidate the previous key.

The TfL API uses these keys for authentication. While some APIs employ more complex authentication flows like OAuth 2.0, TfL's direct key-based method simplifies initial setup for many use cases. For securing API keys in client-side applications, practices like using a proxy server or environment variables are recommended, as detailed in general API security best practices.

Your first request

With your App ID and App Key ready, you can now make your first authenticated request to the TfL API. This example demonstrates how to retrieve the status of all London Underground lines using a common tool like cURL, which is available on most operating systems.

API Endpoint for Line Status

A good starting point is the Line Status endpoint, which provides information on the current operational status of each tube line. The base URL for the TfL API is https://api.tfl.gov.uk/.

The specific endpoint for all Line Statuses is: /Line/Mode/tube,dlr,overground,tflrail/Status

Constructing the Request

Your API keys need to be appended as query parameters to the URL. The parameters are app_id and app_key.

curl "https://api.tfl.gov.uk/Line/Mode/tube,dlr,overground,tflrail/Status?app_id=YOUR_APP_ID&app_key=YOUR_APP_KEY"

Replace YOUR_APP_ID and YOUR_APP_KEY with your actual credentials obtained from the TfL developer dashboard.

Executing the Request (cURL Example)

Open your terminal or command prompt and paste the modified cURL command. Press Enter to execute it.

A successful response will return a JSON array containing objects, each representing a line with its current status. For example:

[
  {
    "$type": "Tfl.Api.Presentation.Entities.Line, Tfl.Api.Presentation.Entities",
    "id": "central",
    "name": "Central",
    "modeName": "tube",
    "disruptions": [],
    "lineStatuses": [
      {
        "$type": "Tfl.Api.Presentation.Entities.LineStatus, Tfl.Api.Presentation.Entities",
        "id": 0,
        "statusSeverity": 10,
        "statusSeverityDescription": "Good Service",
        "reason": "",
        "created": "2026-05-29T10:00:00Z",
        "validityPeriods": []
      }
    ],
    "serviceTypes": [
      {
        "$type": "Tfl.Api.Presentation.Entities.LineServiceTypeInfo, Tfl.Api.Presentation.Entities",
        "name": "Regular",
        "uri": "/Line/Route?ids=Central"
      }
    ],
    "crowding": {
      "$type": "Tfl.Api.Presentation.Entities.Crowding, Tfl.Api.Presentation.Entities"
    }
  }
  // ... more line status objects
]

This JSON output indicates that the Central Line is currently experiencing "Good Service." The response structure will vary slightly depending on the endpoint, but the general format will be JSON.

Alternative: Using a Browser

For simple GET requests, you can also paste the full URL (with your App ID and App Key) directly into your web browser's address bar. The browser will display the raw JSON response, which can be useful for quick checks.

Common next steps

After successfully making your first API call, consider these next steps to further integrate with the Transport for London API:

1. Explore More Endpoints: The TfL API reference documentation lists all available endpoints, including those for journey planning, station information, disruption alerts, and more. Identify the data relevant to your application's needs.
2. Implement in a Programming Language: Move beyond cURL and integrate the API calls into your preferred programming language (e.g., Python, JavaScript, Java). Most languages have HTTP client libraries that simplify making web requests and parsing JSON responses. For instance, Python's requests library is a common choice for this purpose.
3. Handle Data Effectively: Learn to parse the JSON responses efficiently. Understand the structure of the data returned by different endpoints and how to extract the specific information you need for your application. Consider using JSON parsing libraries relevant to your programming environment.
4. Error Handling: Implement robust error handling in your code. The TfL API will return specific HTTP status codes and error messages for issues such as invalid keys, rate limits, or malformed requests. Refer to the API documentation for a list of common error codes and their meanings.
5. Rate Limits: Be aware of the API rate limits. While standard access is free, there are limits on the number of requests you can make within a given time frame. Consult the TfL API portal for details on current rate limits and how to request higher limits if necessary.
6. Webhooks (if applicable): Some APIs offer webhooks for real-time notifications about data changes. Check the TfL documentation to see if webhooks are supported for events relevant to your application, such as major disruptions. If available, webhooks can reduce the need for constant polling. For general information on webhook implementation, see Twilio's webhook documentation.
7. Caching Strategies: Implement caching for data that doesn't change frequently to reduce API calls and improve application performance. For example, station lists or line names can be cached locally rather than fetched with every request.
8. Monitor Usage: Regularly check your API usage statistics on the TfL developer dashboard to ensure you stay within your allocated limits and to understand your application's data consumption patterns.

Troubleshooting the first call

Encountering issues during your first API call is common. Here are some troubleshooting steps for typical problems when interacting with the TfL API:

1. Incorrect App ID or App Key:
   • Symptom: You receive an "Unauthorized" (HTTP 401) or "Forbidden" (HTTP 403) error.
   • Solution: Double-check that your App ID and App Key are exactly as provided in your TfL developer dashboard. Ensure there are no typos, extra spaces, or missing characters. Remember that these keys are case-sensitive. Regenerate your keys if you suspect they might be compromised or incorrect.
2. Missing Parameters:
   • Symptom: The API returns an error indicating missing or invalid parameters, or a generic "Bad Request" (HTTP 400).
   • Solution: Verify that app_id and app_key are correctly included as query parameters in your URL, separated by an ampersand (&). Ensure they are not accidentally placed in the request body or headers instead of the URL query string.
3. Incorrect Endpoint URL:
   • Symptom: You get a "Not Found" (HTTP 404) error.
   • Solution: Compare your request URL against the TfL API reference documentation. Ensure the base URL (https://api.tfl.gov.uk/) and the specific endpoint path are correct, including capitalization and slashes.
4. Network Connectivity Issues:
   • Symptom: The request times out, or you receive a "Connection Refused" error.
   • Solution: Check your internet connection. If you are behind a corporate firewall or proxy, ensure it is configured to allow outbound connections to api.tfl.gov.uk.
5. Rate Limit Exceeded:
   • Symptom: You receive an error indicating too many requests (HTTP 429).
   • Solution: You have exceeded the number of allowed API calls within a specific timeframe. Wait for the rate limit period to reset before making further requests. Review your application's logic to minimize unnecessary calls and implement caching where appropriate.
6. JSON Parsing Errors:
   • Symptom: Your application fails to parse the API response, even if the HTTP status code is 200 (OK).
   • Solution: The TfL API returns JSON. Ensure your parsing library is correctly configured to handle JSON data. Sometimes, an API error message itself might not be valid JSON, so check the HTTP status code first before attempting to parse the body as JSON.
7. Browser Caching (when using browser for testing):
   • Symptom: You see old data even after changing parameters or regenerating keys.
   • Solution: Browsers sometimes cache API responses. Clear your browser's cache or use an incognito/private browsing window for testing to ensure you are getting fresh data.