API for developers

Questi contenuti non sono ancora disponibili nella tua lingua.


Why	Give a hotel’s developer — or an integrator — a starting point: what the API is, where its specification lives, and how access works.
Who	A developer connecting their own system to HotelsCalendar; a property owner who needs to brief a contractor.
What you’ll get	A clear picture of the API’s surface — what data it can retrieve — and of the access process: a token and a base URL.
Limitations	This is a starting point, not a method reference: the full list lives in the specification, and technical limits are not published.

HotelsCalendar has an API: the same bookings, availability, and guests you work with in the interface — programmatically. This page is the starting point: what the interface is, where its specification lives, and how to get access. There are no code samples here — the specification replaces them.

What the HotelsCalendar API is

The API is a programmatic interface on top of the product. It serves and accepts the same data as the PMS interface: bookings, availability, guests. The interface is for people; the API is for software — an accounting system, a script, or a spreadsheet can read and update property data without manual re-entry.

The data speaks the same language as the articles in this documentation: bookings with statuses and guests, availability per date, guest data. That is why any integration starts with understanding how the product describes these entities.

The specification

The complete description of the API is its OpenAPI specification, the openapi.yaml file: it lists every method — what each one accepts and returns — and the data models. The specification is grouped into roughly 24 thematic sections.

The specification can be viewed and downloaded via the API’s base URL — the address issued together with your access. It is the source of truth on capabilities: everything it describes, the API can do; anything it does not list, the API does not promise.

Authorization

Access to the API is token-based: a personal key sent with every request. The token tells the API which property a request comes from and what that access is allowed to do.

The token and the base URL arrive together, when your access is set up (see below for how to request it). Treat the token like a password: it opens the property’s data, so it stays on your side and is never published.

Typical scenarios

Your own analytics. Bookings are exported into your BI tool or spreadsheet, where they are counted the way you need — with no manual export every month.
Syncing with internal systems. The property’s accounting software or back-office service receives bookings and changes from the PMS, so the systems never drift apart.
Small tools and widgets. A lightweight tool on top of property data — an internal page for staff, a summary for the manager — that reads from the PMS directly.

All three scenarios follow the same path: get a token, find the methods you need in the specification, connect your system.

What is not there

Technical limits of the API — request frequency, export sizes — are not published in this article.
The list of capabilities is the specification alone: methods and models are described by openapi.yaml, and this article promises nothing beyond it.
How the API evolves over time — version compatibility, how changes are communicated — is not promised on this page either: the terms are agreed when your access is set up.
There are no step-by-step code tutorials here either — the specification plays that role.

How to get access

Write to us via the “Contacts” page on the HotelsCalendar website: describe your task — which system you are connecting and what data it needs.
We will send you a token and the API’s base URL.
From there, follow the specification: find the methods that fit your task and connect your system.

If your question is about running the property rather than development, start from the support page instead.