Onboarding Guide for Property Portal Product Managers

Getting Started with TravelTime for Property

Congratulations! If you're reading this onboarding guide, you're already on your way to choosing the right location or commute time API for your property portal.

You likely already understand the value of integrating commute times into your platform and now it's time to bring the right teams together to start exploring how it all works in practice.

This short guide walks you through the key considerations based on our experience helping property portals move from idea to implementation and optimisation.

Let's get started.

Phase A: Define the Use Case

In the first phase, we recommend taking time to define the business goals that integrating commute time functionality will help you achieve. Consider what your ideal user journey looks like and the API functionality you'll need to bring it to life.

Success Metrics

What goals are you looking to achieve by implementing a commute time functionality, and what metrics will you measure to ensure that it has been successful? Common metrics we see our property portal customers targeting with TravelTime are:

Conversion Rate

Users that interact with commute time features through a search or on a listing page are more likely to convert because they have more personalised insights to support their property search decision-making.

Lead Quality

Commute time data helps users discover properties that are a better match for them, therefore becoming better leads for agents.

Bounce Rate & Time on Site

Displaying personalised commute times on listings means that users do not have to leave your site to calculate their commute on Google Maps or an equivalent third-party provider.

Account Creation & User Login

Giving logged-in users the ability to save their key locations and preferred transport modes makes results more relevant and personalised. This enhances the user experience, and encourages account creation and repeat logins.

User Retention

Providing an accurate commute-time functionality gives your portal a competitive edge. The improved, more personalised experience encourages users to return again and again.

Property Search and Discover Experience

What changes to the user experience do you want to implement? Based on our work with leading property portals, the most popular enhancements include:

Search by Commute Time

Allow users to search for properties and filter the results using their preferred maximum commute time and transport mode.

Enrich the Search Results Page

Display personalised commute times directly on each property listing card to help users compare listings on the results page at a glance.

Enrich the Property Listing Page

Show default travel times to nearby points of interest e.g. train stations, schools, or any other available POI data your portal uses.

Additionally, allow users to set their own important places or POIs, and display travel times to those locations on each property listing.

Time-based Mapping

Display all available properties on a time-based map so users can instantly see which areas are reachable within their preferred travel time from a starting location.

NLP AI Search

Allow users to search for properties with natural language, free-text. Empowering them to search in a way that suits them.

Choose an Endpoint

Which endpoint best supports your use case? With TravelTime, you get unlimited access to our full suite of API endpoints. Each designed to support different types of functionality and use cases.

Travel Time Matrix

Calculate large volumes of travel times simultaneously. This TravelTime endpoint allows for up to hundreds of thousands in one request.

• Calculate hundreds of thousands of travel times at once
• Our highest-performance option for implementing a commute-time search filter
• Ideal for displaying commute times directly on search results or property listing pages

Isochrones

Generate travel time areas as polygons that represent how far a user can travel within a set time by the chosen transport mode. Think of this like a radius but measured by time instead of distance.

• Generate a reachable area as a shape
• Use these polygons to filter properties within a reachable area
• Visualise accessible zones and filtered listings directly on a map for an engaging user experience

H3

Calculate travel times to individual reachable H3 cells. A similar concept to isochrones, but instead of creating a single polygon, H3 calculates travel times for all locations within the maximum travel time.

• Calculate commute times to all reachable H3 cells
• Lightning fast to render on a map, allowing efficient filtering without point-in-polygon calculations
• Perfect for showing additional spatial context beyond the binary isochrone view

Routes

Generate detailed A-to-B routes with turn-by-turn directions for journeys of up to 12 hours, using driving, public transport, walking, and cycling models.

• Calculate multimodal route anywhere in the world
• Return direction, durations, and distances for each journey
• Power routing views, journey summaries or confirmation screens alongside listings and maps

Phase B: Evaluate the API

Now it's time to test the performance, scale, accuracy, and reliability of TravelTime API. This phase helps you determine whether TravelTime is the right partner for your property portal.

We are very confident that we will meet—even exceed(!)—your expectations, but it's always worth testing.

Performance

Interactive Playgrounds

The simplest way to get an understanding of the API's performance is to start sending requests through our interactive playgrounds. These are ideal for product managers, UX designers, and developers who want to explore how the endpoints behave before any code is written — and you don't need an API key to use them.

• Travel Time Matrix Playground – Try out commute-time search filters and see how quickly results are returned.
• Isochrones Playground – Generate time-based catchment areas and view them directly on a map.
• H3 Playground – Experiment with travel time data and see how H3 cells render on a map.
• Routes Playground – Explore A-to-B journeys and view full routes, timings, and directions on a map.

Keep an eye out for the response time in the top right corner.

Server-to-Server Benchmarks

Once your team is comfortable with how the endpoints work, we recommend running server-to-server performance benchmarks from your own infrastructure, using our K6 benchmarking tool.

This step is usually led by backend engineers or DevOps/SRE teams, and requires a TravelTime API key (available via a free trial or existing account).

This combination of quick, no-key testing in the playgrounds, followed by structured benchmarking with an API key, will give both technical and non-technical stakeholders confidence in how the TravelTime API will perform for your use case.

Scale

For large, high-traffic property portals, meeting the needs of property seekers means using a solution that can scale alongside your users and content. When evaluating scale, it's helpful to consider:

• How many travel times you need to calculate
• How much traffic your portal generates
• Which countries and transport modes you need to support

Can individual API requests support the number of travel times you need to calculate when using the Travel Time Matrix endpoint?

If you're using the Travel Time Matrix endpoint, you'll want to know how many travel times can be returned in a single request.

Our highest-performance matrix endpoint can calculate up to 200,000 travel times in one request, making it well suited to large property inventories and high-traffic portals.

Can the API support your portal traffic?

We support customers with tens of thousands of requests per minute. Our technology is used by some of the world's highest-traffic platforms, including Realtor, Rightmove, and CoStar.

However, we still encourage you to run load tests to simulate full production-level traffic to the API. This will give your engineering team confidence that performance meets your specific needs.

To get set up, reach out to support@traveltime.com and we'll get you access to run these tests.

Does the API support all the countries you are live in?

TravelTime provides walking, driving, public transport, and cycling data across the globe, and is live in 200+ countries and territories. Check the full list of Supported Countries to make sure we have you covered.

Accuracy

Quick checks with known routes

To quickly test the accuracy of any route that you know, using any mode of transport, you can use our Routes Playground. Just plug in your origin, destination, and transport mode to compare the results with your expectations or real-world experience.

Drive-time comparison with other providers

For a more in-depth comparison of drive times, you can use our open-source Drive Time Comparisons tool. This allows you to benchmark TravelTime against other providers such as Google, TomTom, and HERE across a set of routes that matter to you.

Public transport data coverage

When it comes to public transport, you can use our Coverage Tool to see exactly which public transport data we have, and where. This helps you confirm whether we cover the locations and modes that are important for your users.

Reliability

For many of our customers, it's critical that TravelTime is live and working reliably at all times. And we take that responsibility seriously.

You can see the service uptime for all our API endpoints for the last 365 days by visiting our Status Page, giving your team full transparency into historical availability and any past incidents.

Pricing Model

Price is an important part of any decision. At TravelTime, we price differently to many other location APIs, which means a direct like-for-like comparison isn't always totally straightforward.

Most alternative providers charge per API call. As more people use your commute tool, these costs can grow quickly and become hard to predict.

TravelTime takes a different approach. We agree a fixed, annual value-based price with you after discussing factors such as:

• Your expected HPM (hits per minute)
• Your caching strategy
• Your anticipated traffic and usage patterns

This model is designed to give you cost certainty as your usage scales. Compare alternative Distance Matrix pricing and Isochrone pricing scenarios for yourself in these blogs.

Phase C: Integration

It's now time for your engineering team to get hands-on with the API and begin the integration. We've invested a lot of effort into making sure developers enjoy working with our technology, from clear documentation to intuitive endpoints.

To ensure you're fully confident in the solution before making any commercial commitment, we're happy to support a proof of concept period. During this time, your team can implement and test the API at no cost, giving you space to validate the integration in a real environment.

API Access

TravelTime access is through an API key. Once you're ready to start testing, sign up for an account to get access to your key.

We don't operate a sandbox environment. Instead, you can begin building and testing on production right from day one. If you need multiple API keys to split different streams of development and testing, just contact support@traveltime.com and we'll get you set up.

Integration Options

We support a range of integration options, so your team can build in the stack that they are already using. If you're not sure which approach is best, we're happy to walk through the options with your engineers and recommend a path that fits your architecture.

Choose from the approaches below:

SDKs

SDKs with full feature compatibility, supporting all endpoints.

• NodeJS
• Java
• Ruby
• Python

Database Plugins

Fully supported integrations right into the database search level.

• ElasticSearch
• Solr

Direct HTTP Requests

Make direct HTTP requests. Get started with our Postman Collection.

Architecture

The TravelTime service is always accessed via our API, so you don't need to host any models or data yourself. You also don't need to share your property data with us for mirroring — the requests you send simply combine your inputs (locations, times, modes of transport) with our datasets and return the results.

Below is a simple architectural view of how the H3 endpoint can be used to filter properties by travel time and display the reachable area on a map in your front end. This pattern can be adapted to fit your existing services and infrastructure.

Exactly how you choose to implement the service and build commute times into your portal is entirely up to you.

We're always available to support, advise, and answer questions — but your teams are, and should remain, the experts in how your systems are designed and built.

Front End Design

As with the architectural design, we believe that your teams are best placed to create the best user experience when implementing the TravelTime API. You know your users, brand, and product patterns better than anyone, and TravelTime is designed to fit into those. Not replace them.

Take a look at how other TravelTime customers have implemented the API from a UI perspective.

Setting API Parameters

The TravelTime API is built to be highly configurable, with a wide range of parameters available. When designing your interface, you'll need to decide which parameters to expose to users and which to set behind the scenes and populate automatically.

We generally recommend showing only the essential parameters to your end users:

• A location e.g. workplace, school, or other important place that your users want to live near
• A transport mode - driving, public transit, walking, or cycling
• A maximum travel time in which the user is happy to travel to/from the location and a property

All other parameters can be populated automatically with the defaults or settings that produce the results you want. This keeps the experience clean and easy to use, while still giving your team full control over how the API behaves under the hood.

Phase D: Go Live

Proof of Concept

To ensure that you are 100% confident in the solution before making a commercial commitment, we are happy to support a proof of concept test period. During this time the API can be implemented at no cost.

Throughout the POC, you're treated like a paying customer, with full access to our support and technical teams whenever you need assistance. This gives you the space to validate performance, user experience, and internal fit in a real environment before you decide to roll out more widely.

Ongoing Support

We believe that support should always be human and delivered by real experts.

We set up shared Slack channels so your technical teams can talk directly to our technical teams. You'll be talking to the engineers and specialists who have built the TravelTime technology and are best placed to help with any questions or edge cases.

TravelTime is unique in that all of our technology is built in-house — we're not just a wrapper around other providers. This means we can offer deep, in-depth support across both the technology and the underlying data, from initial integration through to long-term optimisation.

What's Next?

By now, you should have a clear picture of what it takes to bring commute times into your property portal — from defining your goals, to testing performance, to planning your integration and going live.

Depending on where you are in your journey, you might:

• Share this guide internally with product, engineering, and UX teams so everyone has a common understanding of what's possible.
• Define a first use case and agree what success would look like.
• Set up API access and start exploring the playgrounds and test endpoints with real locations and journeys that matter to your users.
• Plan a proof-of-concept period, including who will be involved, what you'll test, and how you'll evaluate results.

We provide support at every stage. Sign up for a key, or get in touch with support@traveltime.com with your questions and ideas to get started.