We at Triposo have built an amazing travel content platform over the past 5 years
and are excited to launch the beta version of our API.
Our API allows you to get access to all the goodness of Triposo. Our content is
multi-dimensional and has locations, activities, articles and points of interest -
all with a relevant score and multiple ways to filter and sort it.
Our API console allows you to easily access your API credentials, reference
documentation and sample queries.
It also includes a fully-documented, interactive API Browser that allows you to
explore and understand the capabilities of the Triposo API.
Our data is organised around a number of data models, each of which is accessible
via the corresponding API endpoint. Most of the models are also related to each
other, so that, for example, you can find the top-rated city in France and then
find highlights for that city.
Below is a brief introduction to each model.
A Location can be a city/town, a country, an island, a nature reserve or a region
(part of a country).
Locations are contained within a hierarchy which can be queried by use of special
tags. To find the top 10 cities in France you could simply do:
Tags are used to classify the models and add additional dimensions to our scoring.
Each tag in a location has a tag label associated with it, such as
sightseeing or cuisine-Pizza. Each such label is unique
within a location, but generally appears in multiple locations; for example there
is a tag with label sightseeing in nearly every city in our database.
Tags are organised into a hierarchy, and can be queried based on that hierarchy.
Thus you can find all cuisine-related tags in a city, for example, by querying for all the tags in that city
that have a tag labelled cuisine as an ancestor:
If a POI belongs to a given tag, it will also belong to all of that tag's ancestors.
Some tags are considered "internal", meaning that they're not normally relevant to show to end users.
The cuisine tag is an example of such a tag: it is not normally interesting to know that
a POI belongs to such a tag, or to find all POIs belonging to it.
However, it is useful for finding more-specific related tags like in the above example.
A list of standard tags can be found in the
or by querying the common_tag_labels endpoint,
and more examples of working with the hierarchy can be found in the
The tag model can also be used to find the best places for a certain tag in the
world. For instance the best places for diving:
The tag model is also used for districts within a location, if you want to find all tags for that district
you can use the related_labels parameter.
For example, you can find all the tags in "The Rocks" in Sydney:
Tours are organized by our partners and allow travelers to experience a destination
through the eyes of an expert. We have a large database of tours from different
providers which you can filter and query much like POIs. We have also done the hard
work of matching tours to POIs so you can check for tours that include top
Each tour result includes a link to the tour on our tour partners' websites. When
you provide your affiliate IDs in the API Console they will be passed through to
the relevant tour vendors so that you get the commission for any sale resulting
from a user following such a link.
We pride ourself on our depth of content. Besides the POI and location models we
also have background articles that give you detailed information about a
destination. These vary from articles about animals or artworks to complete history
& background information about a city.
You can find articles by matching with a location ID and/or by using tags.
This model holds various properties of POIs, locations and tours. The property
endpoint normally does not need to be queried directly, since the properties can be
included in the results of a POI, location or tour query simply by specifying that
you wish the properties field to be included in the result. In the case of POIs the
properties can include information such as the URL of the POI's website, its phone
number or its opening hours. For locations it can include information like
population or area.
For example, here is the information for Tivoli Gardens in Copenhagen:
Much of our content is sourced from partners and open content sources. Each of
these have their own attribution requirements. This model provides information
about the license and attribution requirements for each source.
For instance, this query provides attribution information for content from
They say the best way to experience a city is to “walk” it. This endpoint returns a list of
POIs that are ideal for a walk based on the destination and walk time. Our algorithm
automatically picks high scoring places of interest across sightseeing, food and other categories.
For instance, this query will give you a 200-minute walk through Prague:
Planning your day in a city can be tiresome. The day planner makes it as simple as one API call.
Add your destination and trip duration and get a complete plan that covers highlights and hidden gems.
Not to forget the recommendations for breakfast, lunch and dinner.
For instance, this query will give you a day plan for a 3 day trip to Lisbon, staying at the
Finding out where to stay in a destination is an important part of a trip. With the local scores feature you
get scores for four selected categories (sightseeing, eating out, nightlife and shopping) for the
coordinates you supply. This end point is ideal for online accommodation providers and discovery portals.
For instance, this query will give you the scores for Forum Romanum in Rome and the Wallen in Amsterdam: