We at Triposo have built an amazing travel content platform over the past 9 years.
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.
API Console
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.
API version lifecycle
Every API version is normally being supported for two years since its launch.
The version's release date is simply its name, as an ISO-formatted date.
To discover details about API versions' life cycle, refer to the API version lifecycle policy page.
The Models
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.
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
reference documentation
or by querying the common_tag_labels endpoint,
and more examples of working with the hierarchy can be found in the
sample queries.
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
attractions.
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.
Article
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
Wikipedia:
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:
Travelers often ask themselves what is good nearby. With Local highlights you get a list
of great food, nightlife and sightseeing options closest to a specific point.
For instance, this query will give the local highlights near Ipanima beach in Rio de Janeiro:
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
'Travellers House':
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:
You can find details of all the parameters for each endpoint in the
reference documentation,
but some parameters can be specified for most endpoints; these are discussed below.
fields
By default, the records returned by the API typically contain a subset of the available fields, in order to
limit the size of the response.
You can find a complete list of fields for each type and which ones are included by default in the
reference documentation.
If you wish to have a different set of fields returned, in order to leave out fields you're not interested in
or to include fields left out by default, you can specify this using the fields
parameter, e.g.:
Note that, by default, the fields parameter only affects the return type of the endpoint; nested
records of other types (such as the tag records nested inside the tags field in the
above example) will still contain the default fields.
To specify the fields for any given type, just add the type in front of the list of fields, separated by a
colon; if you wish to specify fields for more than one type, you can do this by specifying the
fields parameter multiple times.
For example, to change which fields are included in the property records in a POI response:
Note that specifying the fields parameter without a type is equivalent to specifying it with the
type returned by the endpoint, so that the above query (which returns records of type poi) is
equivalent to:
API requests usually return a list of items.
In such cases the count parameter can be used to specify how many items should be returned.
By default 10 items are returned, but you can request up to 100.
For example, if you want only 5 points of interest in Amsterdam:
Sometimes you may wish to retrieve more records than can be returned in a single request (100).
In such cases you can specify an offset to retrieve subsequent records.
For example, to retrieve POIs beyond the first 100:
By default, records are returned in reverse score order (highest score first).
You can use the order_by parameter to specify that they should be ordered on some other field of
the return type, as long as that field is orderable.
You can find out which fields are orderable in the
reference documentation for types;
some annotations are also orderable (see the
reference documentation for endpoints).
For example, you can find the places to go for drinks in Bangkok that are no further than 1km from a particular
point, order them by the distance from that point and return the first (i.e. closest) 10:
Note that the default ordering is from smallest value to largest; if you wish to have results sorted from
largest to smallest (e.g. to return items with highest score) then the order_by condition can be
negated.
For example, you can order the above POIs by which ones are best for drinks rather than how far away they are:
For extra flexibility, the order_by parameter accepts expressions built from numbers and orderable
fields using the *, +, -, /, ** and unary
- operators
(just make sure that you encode any use of + so that it is not converted to a space).
For example, here's a more complex expression that balances score against distance: