Register the four entity types on your account

By the end you will have one of each of the four entity types on your account — an accommodation, a location, a location search and a flight — which is what every Feed and Real Time endpoint asks you to point at.

What you need: a Veetal API key. Nothing else — the account endpoints are free and open to every key.

What it costs: nothing in the dashboard. Creating entities is free, and so are the Booking resolution and the OTA profile search the wizards run while you create them — you only pay when you ask for data about them. Over the API two of those lookups are requests of their own; the API section at the end says which.

What an entity is, and why there are four

An entity is a thing you have told Veetal to watch. The endpoints don't take free text: they take your identifiers. Which type you need depends on the question:

All four live under My organization, each on its own tab, and all four can also be created from the + button in the header. If you open the wizard from an API page instead, it adds a final step to put the new entity straight onto that API's schedules.

1. Accommodation — the hotel

On the Accommodations tab, Add accommodations. The wizard opens on three routes:

Search Booking accommodation is the usual one. I have accommodation Booking URL is for when the search is ambiguous and you already have the listing open. Import accommodations from .csv/.xls file is the bulk route.

Search by name. The results carry the hotel's photo and city, and the ones already on your account are greyed out and marked It's yours — which saves you the duplicate:

If nothing matches, use fewer words: the search matches Booking approximately, not your exact string.

Pick one and Continue. Veetal now resolves the listing for real and shows you what it found — stars, guest score, review count, address — plus Profiles Found: which OTAs this hotel actually has a listing on.

In this example Booking, Tripadvisor and Google were found; Expedia and Hotels.com were not. That matters later: an OTA with no profile has nothing to import, and the reputation feed will only return the ones with a green tick. Repeat search profiles runs the detection again if you think it missed one, and View Profile opens the listing it matched so you can check it is the right property.

Add accommodation, and the hotel joins the list on the Accommodations tab. Its SETUP column is that same profile map, one badge per OTA — here on other hotels of the account:

One thing worth knowing: the slug Veetal assigns comes from the Booking URL, not from the display name. "Ohla Barcelona" became ohla. The slug is what every endpoint takes, so copy it from the row rather than guessing it.

2. Location — the destination

The Locations tab, Add locations. The dialog says what it is for: "You will use them to search events in the destination".

Search the destination and you get why this step exists at all:

Four Barcelonas — Spain, Venezuela, Colombia, the Philippines — each with its own coordinates and a Show Map to check. Pick the wrong one and every event you read afterwards is for the wrong city.

Add location and the row lands with its type — Tier 1 here — and its coordinates:

3. Location search — the destination, filtered

The Location searches tab, Add location searches. The finder is richer than the location one: as well as the city it offers districts, the airport, the province and landmarks like the Fira, because a "market" can be any of those.

Step two is the point of this entity — the filters:

Country, currency and language (they change the prices Booking shows), board, stars, property type, and further down distance from centre, minimum score, free cancellation, pet friendly, nights, adults, children, babies and rooms.

These filters are the entity. They define which hotels the search covers — your competitive universe. They do not change the price: a run of the feed is billed per location search and per night, however many hotels the filters let in. The example here is 4 and 5 star hotels in Barcelona, one night, two adults. Add location search, and the row shows the filters back as chips:

4. Flight — the route

The Flights tab, Add flights. This is the most self-contained of the four: airports are resolved locally, so it works even when the OTAs don't.

Type a city and you get its airports with their IATA codes. London gives seven — six around London, UK, and one in London, Ontario (YXU) — so read the country before you pick:

Then trip type, dates, passengers, and two fields that are required and easy to miss: LANGUAGE and COUNTRY. They are the point of sale — the market whose prices you want — not the route. Leave one empty and the field turns red with This field is required and Add flight stays disabled.

A Round trip needs a date range; One way takes a single date.

The same thing over the API

Every one of the four has a matching account endpoint, but each takes its own body:

A GET on the same paths lists what you have. Locations, location searches and flights answer { data: [...], pagination }. Accommodations answer an object keyed by slug — the slug the data endpoints take — and only with your own active hotels: deactivated ones and competitors are left out, and a hotel without a slug is keyed by its id.

Three things the wizards do for you, and that you do yourself here:

• OTA profiles. Creating a hotel from its Booking URL resolves Booking only. The search for its other profiles is POST /v3/account/accommodation/{accommodation_id}/otas, billed by what it finds: the share of the OTAs it fills, up to the price of one Real Time request, and nothing if it finds none. force_otas (for example ["expedia"]) searches again the ones that already have an id.
• The destination id. booking_dest_id is the booking_id that GET /v3/real-time/booking/search/{type}/{name} returns, and that search is a Real Time request. A location takes a city, region, country or district; a location search also takes a landmark or an airport. Any other type answers error 732. The name is not compared with Booking's: it is searched on Booking, and the destination id has to come back among the results. Send the name the search returned and it will; a name of your own can miss it and fail with error 731.
• The point of sale. language and country are optional here. A flight created without them is saved as es / ES — Spanish fares, without a warning. Send them.

What happens next

Entities on their own don't fetch anything. From here the path forks: a Real Time endpoint will answer about them immediately, one request at a time; a Feed dataset needs an import to have run first, which you set up as a schedule on that API's page. Each row also has activate, deactivate and delete, and the checkboxes give you the same three in bulk — a deactivated entity stops being imported, and what earlier imports wrote stays readable until it ages out (rates, parity, reputation, location search and flight data are kept 15 days; reviews, events and market demand are not deleted).