Triposo API 20211011

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.

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.

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.

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. For more information you can look at more examples, the reference documentation or a discussion of common query parameters.

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:

It's also possible to look up locations by (partial) name by applying the trigram similarity annotation and then filtering the results:

POIs are at the core of our content database and include sights, restaurants, parks, bars, hotels, discotheques and more.

There are several ways to find the POIs you are interested in. The most comprehensive way to go about it is to use tags (see below for more on these).

For example, if you're interested in all the places that serve pizza and beer in Amsterdam:

Or maybe you wish to find a park near the Eiffel Tower:

Or you could find the places most similar to Ippudo London in Amsterdam:

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.

Interested in a cycling tour in San Francisco?

Interested in tours that include the Eiffel Tower?

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.

Wondering about art in Barcelona?

Wondering about celebrations in Istanbul?

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:

Walks can be customized based on specific start coordinates and tag labels:

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:

You can also restrict the search to only contain certain categories, in this case sightseeing and some local cuisines in Tokyo:

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:

Finding out where to go for a certain thing in a big city is important to enjoy your stay. With the best_district endpoint you can do this easily.

For instance, this query will give you the best district in San Francisco to eat chinese food:

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.:

You can also use the special value all to return all fields:

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:

count

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:

offset

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:

order_by

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:

For more detail on our API requests and responses, please sign up for our beta program.

Once you get your API credentials, you will get access to the API browser, reference documentation and sample queries.