Transport for Auckland Getting Started: API Access (2026)

Getting started overview

Transport for Auckland (AT) provides developers with access to public transport data and parking information, primarily through their General Transit Feed Specification (GTFS) feeds and the AT Park API. This guide outlines the steps to quickly get access to these resources and make your initial requests. The process emphasizes straightforward access for non-commercial applications, which can typically begin integrating data without formal API keys for the GTFS feeds themselves, directly downloading the archives. For the AT Park API and commercial use cases, specific registration and key acquisition steps are necessary.

The AT developer portal serves as the central hub for all documentation, data links, and support queries. Developers can leverage the provided data to build applications for journey planning, real-time vehicle tracking, service alerts, and parking availability. Understanding the distinction between direct GTFS feed access and the AT Park API's key requirements is crucial for a smooth onboarding process.

Before proceeding, it's beneficial to review the officially supported methods for consuming GTFS data, which often involves parsing protocol buffers or JSON representations of the data, as detailed in the Google Transit documentation on GTFS. While AT provides the data, adherence to GTFS standards means that general tools and libraries for GTFS can often be applied.

Create an account and get keys

For non-commercial access to the core GTFS feeds (real-time and scheduled), Transport for Auckland generally does not require a formal API key or account creation. These feeds are often publicly accessible for direct download. However, for commercial use or access to the AT Park API, specific steps are required:

GTFS Feeds (Non-Commercial)

1. Visit the AT Developers Portal: Navigate to the Transport for Auckland developers page.
2. Locate GTFS Feeds: On the portal, find the sections dedicated to 'Real-time GTFS' and 'Scheduled GTFS'.
3. Download Feeds: Directly download the GTFS data archives. These are often provided as .zip files containing various .txt files (for scheduled data) or as Protocol Buffer files (for real-time data). No account or key is typically needed for these direct downloads for non-commercial purposes.
4. Review Usage Terms: While direct access is common, always review the specific terms of use for Transport for Auckland data to ensure compliance, even for non-commercial projects.

AT Park API and Commercial Use

The AT Park API, which provides parking availability information, and any commercial application leveraging AT data, typically requires registration and potentially API key acquisition. The exact process involves direct engagement with Transport for Auckland:

1. Access the AT Developers Portal: Go to the Transport for Auckland developers page.
2. Identify API Access Information: Look for sections related to the 'AT Park API' or 'Commercial Use' access. These sections will provide instructions on how to proceed.
3. Contact Transport for Auckland: The documentation on the developers portal will direct you to contact AT directly for commercial agreements or AT Park API keys. This usually involves filling out a form or sending an email to their developer support team to outline your project and request access.
4. Receive Credentials: Upon approval, you will receive any necessary API keys, client IDs, or other authentication tokens required to access the AT Park API.

It is important to clearly articulate your project's scope, intended use of the data, and whether it is for commercial or non-commercial purposes when engaging with Transport for Auckland to ensure you follow the correct access pathway.

Your first request

The first request process differs depending on whether you are accessing GTFS feeds or the AT Park API.

For GTFS Feeds (Direct Download)

Since GTFS feeds are often direct downloads, your "first request" involves retrieving and parsing the data locally:

1. Download a GTFS Feed: From the AT Developers Portal, identify and download either a scheduled GTFS (static data) or a real-time GTFS (dynamic updates) feed. For example, download the latest gtfs.zip file for scheduled data.
2. Unzip the Archive: Extract the contents of the downloaded .zip file. You will find several .txt files (e.g., routes.txt, trips.txt, stops.txt).
3. Parse the Data: Use a programming language (e.g., Python, Node.js) and a GTFS parsing library to read and interpret the .txt files. For real-time feeds, you might process a Protocol Buffer stream. Below is a conceptual Python example for reading stops.txt assuming fixed-width or CSV parsing, which is common for GTFS static files:

   import csv
   
   def read_gtfs_stops(file_path):
       stops = []
       with open(file_path, mode='r', encoding='utf-8') as file:
           reader = csv.DictReader(file)
           for row in reader:
               stops.append(row)
       return stops
   
   # Assuming gtfs.zip is extracted to a 'gtfs_data' directory
   # and contains 'stops.txt'
   stops_file_path = 'gtfs_data/stops.txt'
   all_stops = read_gtfs_stops(stops_file_path)
   
   # Print the first few stops to verify
   for i, stop in enumerate(all_stops[:5]):
       print(f"Stop {i+1}: {stop['stop_name']} (ID: {stop['stop_id']})")
   

4. Verify Data: Confirm that you can successfully read and process the data. This constitutes your first successful data retrieval for GTFS.

For AT Park API (Authenticated Request)

Once you have obtained an API key for the AT Park API, you can make an authenticated request. The exact endpoint and authentication method will be detailed in the documentation provided by Transport for Auckland. A common pattern involves including the API key in a request header or as a query parameter.

Example (Conceptual using curl):

Assuming an endpoint like https://api.at.govt.nz/v2/parking/facilities and an API key named Ocp-Apim-Subscription-Key in the header, your first request might look like this:

curl -X GET \
  'https://api.at.govt.nz/v2/parking/facilities' \
  -H 'Ocp-Apim-Subscription-Key: YOUR_AT_PARK_API_KEY' \
  -H 'Content-Type: application/json'

Replace YOUR_AT_PARK_API_KEY with the actual key provided by Transport for Auckland. The response should be a JSON object containing information about parking facilities, such as capacity and real-time availability. Refer to the AT Park API documentation for specific endpoints and required headers.

Common next steps

After successfully making your initial requests, consider these common next steps to further integrate Transport for Auckland's data into your application:

1. Explore Full Documentation: Thoroughly review the Transport for Auckland developer documentation for all available endpoints, data fields, and usage guidelines. Understanding the full scope of the API and data feeds is critical for building comprehensive applications.
2. Implement Real-time Updates: For GTFS Realtime feeds, set up a mechanism to periodically fetch and process updates. This might involve consuming a Protocol Buffer stream or polling an endpoint at regular intervals. Ensure your application can efficiently parse and apply these updates to reflect current transport conditions.
3. Error Handling and Monitoring: Implement robust error handling for API requests and data parsing. Monitor your application's interaction with the AT APIs to identify and resolve issues quickly. Consider logging API responses and errors for debugging.
4. Rate Limiting and Quotas: If applicable to the AT Park API or commercial GTFS access, understand and respect any rate limits or quotas imposed by Transport for Auckland. Implement exponential backoff or other strategies to manage request rates and avoid hitting limits, as described in common API rate limit strategies.
5. Data Storage and Caching: Decide on a strategy for storing and caching GTFS data, especially static schedules, to minimize repeated downloads and improve application performance. For real-time data, consider how to efficiently update cached information without overwhelming your system or the data source.
6. User Interface Development: Begin building the user interface for your application, integrating the retrieved transport and parking data to provide value to users. This could include maps, schedule displays, journey planners, or parking availability indicators.
7. Community Engagement: Look for any developer forums, community groups, or support channels provided by Transport for Auckland. Engaging with other developers can provide insights and assistance.
8. Commercial Agreement Review: If you are developing a commercial application, regularly review your agreement with Transport for Auckland to ensure compliance with terms and conditions, especially as your application scales or its usage patterns evolve.

Troubleshooting the first call

Encountering issues during your first API call or data retrieval is common. Here's a troubleshooting guide:

GTFS Feed Download/Parsing Issues

• Incomplete Download: Ensure the entire .zip or Protocol Buffer file has been downloaded successfully. Corrupted files will lead to parsing errors. Check file size against expected values if available.
• Incorrect File Path: Verify that the path to your GTFS .txt files or real-time data stream is correct in your parsing script.
• Parsing Library Issues: If using a third-party GTFS parsing library, ensure it is correctly installed and compatible with the GTFS specification used by Transport for Auckland. Some libraries might require specific versions or configurations. Refer to the library's documentation for common GTFS validation tools.
• Encoding Problems: GTFS files are typically UTF-8 encoded. Ensure your parsing logic handles UTF-8 correctly to avoid character display issues.
• Outdated Feed: Sometimes, older feeds might have structural differences. Always try to download the latest feed version from the AT Developers Portal.

AT Park API Authentication/Request Issues

• Missing or Incorrect API Key: Double-check that your API key is included in the correct header (e.g., Ocp-Apim-Subscription-Key) and is exactly as provided by Transport for Auckland. Typos are a common cause of 401 Unauthorized or 403 Forbidden errors.
• Incorrect Endpoint: Verify that the API endpoint you are calling matches the one specified in the AT Park API documentation. Slight variations in path or domain can lead to 404 Not Found errors.
• HTTP Method Mismatch: Ensure you are using the correct HTTP method (e.g., GET, POST) for the specific endpoint. Most data retrieval endpoints are GET requests.
• Content-Type Header: For requests sending a body (less common for initial GET requests but important for others), ensure the Content-Type header is set correctly (e.g., application/json).
• Rate Limiting: If you receive 429 Too Many Requests errors, you have hit a rate limit. Implement a delay and retry mechanism, possibly with exponential backoff, to manage your request frequency.
• Network Issues: Confirm your development environment has an active internet connection and no firewall rules are blocking outgoing requests to the AT API endpoints.
• CORS Issues: If making requests from a web browser environment, ensure that the API supports Cross-Origin Resource Sharing (CORS) for your origin. If not, you may need to proxy requests through your own backend server.

General Troubleshooting Table