Condominium Gestionale With an Open API

In the feature list of a gestionale condominiale the entry "open API" shows up often. For a studio that does not write code it looks like an entry for technicians. It is not: it decides whether your data stays locked inside one program or can be connected to the rest of what you use.

What it lets a studio do

An open API is a documented interface: other programs can read and write the gestionale's data in a controlled way, without anyone exporting and re-importing a file. In practice it lets you:

• build your own reports, with the data the standard program does not show;
• connect the studio's website or a request form to the record of requests;
• let a chatbot talk to the real data of a building;
• connect devices (intercom, access control, meters) and bring their status to where the administrator works;
• prepare the export for the accountant in a repeatable way;
• receive a notice when something happens, for example when the status of a payment changes, instead of checking every hour.

With the API you connect payment gateways, banks, smart devices and chatbots; with accounting systems, files are exchanged today.

What a closed system forces you to do

In a closed system every connection is a manual export or a request to the vendor. You re-type the same numbers into the bank, the accountant's sheet and the app, and every missing function is something you wait for from whoever owns the program. With an API you still need the vendor for the things the vendor has to do, but not for every connection.

What to check in a vendor's API

Before choosing, ask these six things:

1. Documentation. Does it exist, is it public, is it up to date? An API without documentation is an API that depends on a phone call.
2. Keys and authentication. How access is obtained, who it is given to and how it is revoked.
3. Limits. How many requests per minute, how much data at a time.
4. Notifications (webhooks). Whether the system tells you when something changes, or you have to poll it constantly.
5. Read and write. What you can only read and what you can also create or update.
6. Plan. Whether the API is included in the price or paid separately.

How it works in Unitify

API access is included in the Pro plan; the price list is on the pricing page. What is there, concretely:

• GraphQL and domain objects. The API is built around objects (for example contacts, requests, users, invoices), each with the same basic operations: read the list, create one, update it. A deleted object does not disappear: it stays with a deletion date.
• Payment notifications. When the payment status of an invoice changes, your system can be notified by a webhook signed with a secret. The address has to be registered in an allowed list, by writing to support.
• Documentation. It is part of the open-source core (MIT license) on which Unitify is built, in the repository github.com/open-condo-software/condo. For the exact list of objects and operations, the documentation is authoritative, not this article.
• Extensions. Mini-apps can talk to the main application through the developer tools that are part of the same core.

What the API is not

It is not a ready-made integration for every system. With accounting programs, files are exchanged today; connecting a specific system is possible and is project work, which we assess by looking at which system it is and what data has to move. Devices are connected through their own interface (API, SIP, ONVIF) under the project, and the payment integrations are the ones already built. And the app interface is not yet in Italian; the API, which talks to other programs, does not depend on it.

The direction: an API for buildings

Our founder argues that buildings will need an open API layer, with the resident's consent, so that an AI assistant can read the data of a single unit: balances, meter readings, status of requests. Today, for a studio, what matters is simpler: the API on the Pro plan and the chance of not being locked into one program. The picture for the Italian administrator is on the Italy page; what a gestionale has to do we set out here, and the integrations to ask for in 2026 here.

If you want to understand whether the API is useful for your studio, book a demo and tell us what you would like to connect.