API – Offen für Austausch



The digitisation of the industry continues to gather pace. Anyone following the developments in the PropTech sector has noticed an increasing number of reports of new cooperations and partnerships within the recent year. Mostly it is two companies integrating their solutions or services or connecting them via an interface (API) – the first small steps towards an asset management ecosystem. A good thing. But… can a comprehensive ecosystem really be built on “exclusive” partnerships? Or are they rather extended isolated solutions and thus solutions that the industry actually wants to say goodbye to? At Architrave we believe that data needs to flow. Without restrictions, and therefore “vendor neutral” – and not just between two applications.


The free flow of data opens up numerous opportunities for digital real estate management. Documents and data that are available on a standardised platform form the basis for a comprehensive and convenient range of services. Architrave customers can calmly take a “digital walk” and select and activate the services they want from a variety of offerings. This also saves a lot of effort in terms of tendering, review, data protection and billing. Through Architrave and smart permission systems, you can provide other PropTechs with the data they need for their use cases. On the other hand, PropTechs save significant acquisition effort and can offer their services directly through Architrave.


Standards are essential for a smooth data flow. On the supplier side, we are all sensitised by now and the gif e.V. is doing a great job here. We were very pleased about the publication of guideline 2.1, whose specifications are seamlessly implemented in Architrave products.

However, it is important to continue to convince and advertise intensively for the implementation of standards amongst asset managers. If slight deviations from the standard are desired, it is simply no longer a standard.


In addition to standards, intelligent interfaces are the key to data exchange. So-called APIs (Application Programming Interfaces) form the technological basis for this. These interfaces define how individual systems and components within an ecosystem can communicate and interact with each other.

The APIs define how and in what form data can be exchanged and consumed by other systems. What the gif directive defines for document classes in our industry, APIs try to do for the exchange of data and documents: create a unified path.

APIs have played an important role in the Architrave software architecture from the beginning and are an integral part of it. So “Architrave API – Since 2013” is more than just a marketing slogan.

In our new developments we use an “API First Approach” too, to focus on open and easily integrated products and solutions that not only promote the exchange of data, but also see it as a foundation.

In the development of our current API and all future interfaces, we make use of de-facto standards in the IT area, such as REST and in the future also GraphQL, in order to not only keep the data exchange as efficient as possible, but also to make the connection effort and use of our services via API as simple as possible.


The provision and successful integration of an API requires detailed technical documentation that provides customers and developers with all functions and necessary parameters.

In this respect too, Architrave is committed to full transparency with the aim of creating an open and cross-industry standard for data exchange. Because only if APIs and their data are generally accessible everyone can benefit.

The documentation of our API is publicly available on Github.

Our API and the associated documentation are continuously being developed further, for example, to integrate new standards or technological developments immediately.


Partnerships are important. Partners form a network. But a network is not an ecosystem. An ecosystem can only be created if ALL participants open up. For this, the formal framework conditions (standards) must be accepted and the technical prerequisites (open APIs) must be created. There is still a lot to do…