Add your hotel and the comp set you price against

By the end you will have a hotel on your account with its slug, its OTA profiles detected and its competitors attached — the setup every comparison endpoint in Veetal quietly assumes you already did.

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 the hotel, resolving it against Booking and attaching competitors are all free. The comp set does change what an import costs later, and that part is worth reading before you launch one.

Why the comp set is not optional

Veetal's comparison endpoints do not take a list of rivals as a parameter. They read the set configured on the hotel. So the size of your comp set decides the shape of the answer:

• Rates come back as { report: { [slug]: [rate, ...] } } — your hotel and every competitor in the same payload. With an empty set, that object has one key: yours.
• Reputation carries a competitors block next to your hotel's, which arrives empty when the set is empty.
• Reviews include the set by default (include_competitors is true): its reviews come in the same reviews list as yours, each tagged with accommodation_slug and is_primary. With an empty set, every review is yours — a solo reading, not a benchmark.
• The live rate grid is one call per property in the set. No set, no grid.

Parity is the exception: it compares what your own hotel costs on each channel, so it does not use the set at all.

This is also the part of Veetal that a plain scraping API does not have. The comp set is stored configuration, not a query parameter you rebuild on every call.

1. Add the hotel

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

• Search Booking accommodation — the usual one.
• I have accommodation Booking URL — for when the search is ambiguous and you already have the listing open.
• Import accommodations from .csv/.xls file — the bulk route, and the sane way to load a portfolio.

Search by name. Results carry the hotel photo and city, and they come tagged:

• It's yours — already one of your accommodations. Greyed out, which saves you the duplicate.
• Is competitor — when you are adding competitors, already one of this hotel's.
• Is existing — already on your account, as a competitor of another of your hotels. Adding it reuses that entity instead of creating a duplicate, which is why it resolves instantly.

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

2. Read the profiles it found

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

That block is a forecast. 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 matched listing so you can confirm it is the right property before it lands on your account.

Once added, the row's SETUP column keeps showing that profile map, one badge per OTA.

3. The slug is not the name

The slug Veetal assigns comes from the Booking URL, not from the display name. "Ohla Barcelona" became ohla.

Every endpoint takes the slug, so copy it from the row instead of guessing it from the hotel's name. Half the "the endpoint returns nothing" tickets are a slug someone typed from memory.

4. Attach up to ten competitors

Open the hotel from the list and add competitors from its detail, with the same finder you used for the hotel — which is why search results already know how to tell you a property Is competitor.

Two things decide whether this step is useful:

Who belongs in the set. A guest choosing your hotel is not choosing between every hotel in the city. They are choosing between the handful in your district, in your band, for their dates. A comp set of ten hotels that a guest genuinely compares beats a comp set of ten hotels that share your star rating and nothing else.

What each one costs. The cap is ten, and it is a cap for a reason: every competitor multiplies the cost of the rates, reputation and reviews imports — a hotel with 5 competitors counts as 6. Reputation and reviews also count each OTA, so 5 competitors across 3 OTAs is 18 listings per run, not 3. Rates are Booking only, and parity reads your hotel alone. The dashboard shows the credit estimate before you launch an import — read it there, not in the invoice.

5. Read the set back from the API

GET /v3/account/accommodation/{accommodation_id}/competitors

Free, like the rest of the Account API. {accommodation_id} is your hotel's internal id, not its slug: GET /v3/account/accommodation lists your hotels keyed by slug, with the id inside each entry.

The answer is an array, one object per competitor: id, name, location and otas, with the Booking slug under otas.booking.slug and the identifiers of every other OTA it was found on. You rarely need those slugs for the feeds: rates and reputation are read with your hotel's slug and bring the set in the same answer. Where they matter is a live rate grid, which loops over the set — one call to get it, then one rate call per property.

To add competitors, POST to the same path with a booking_urls array; DELETE on …/competitors/{competitor_id} takes one out:

curl -X POST "https://api.veetal.app/v3/account/accommodation/YOUR_ACCOMMODATION_ID/competitors" \
  -H "veetal-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "booking_urls": ["https://www.booking.com/hotel/es/YOUR_COMPETITOR.html"] }'

What happens next

The hotel and its set are configuration, not data: on their own they fetch nothing. From here the path forks — a Real Time endpoint answers about them immediately, one request at a time, and a Feed dataset needs an import to have run first.

Two more things worth knowing about the list: every row 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). That is the right move for a hotel you stopped managing, and much better than deleting it.