The official documentation for the onOffice API can be found at apidoc.onoffice.de.
Do you have questions about the API or need help? If so, please contact API Support at firstname.lastname@example.org.
For specific questions about the Marketplace, please contact us at email@example.com.
Some API calls are required specifically for the Marketplace:
- Activation of a provider
- CI colors and logo
- Data of the invoice recipient
- Cancel subscriptions
- Read user photos
- Cancel transaction
- Generate post payment link
API user / parameter extendedclaim:
In each customer version, your API user is present so that you can have read and write access to your customers’ onOffice enterprise version. This is created automatically when the customer activates their service.
The user rights (e.g. which properties or addresses he is allowed to read) of the customer ordering in your store must be respected by your API user. So your API user cannot request more data and perform more actions than the set rights of the client allow.
Therefore, each time the customer calls your service, an “apiClaim” parameter is passed to you. Afterwards you have to return this “apiclaim” as parameter “extendedclaim” for all API calls. This is to ensure that the transfer of the user ID and the customer version is verified. Please use the “apiClaim” from the customer’s latest service call. The validity of the “apiClaim” will be limited in time in the future. Therefore it is not sufficient to always work with the same “apiClaim”.
The “extendedclaim” during unlocking is only valid during unlocking and not for the service calls after activation.
Do not use any other calls during unlocking except unlockProvider. After activating the service, you can retrieve the required data via API.
This parameter will soon be mandatory in the context of the Marketplace. Set this parameter if you use API calls within the Marketplace. The parameter must be set for all API calls listed on apidoc.onoffice.de . Please include this parameter in your API calls as soon as possible.
In addition to the API users in the customer versions, there are also “normal” API users with which you can query information from your vendor version. For more information on creating and setting API users, see the API documentation and online help.
There are 2 API versions, latest and stable. It is at your discretion whether to use stable or latest. The stable version is updated monthly on the first Tuesday of the month. The latest version is updated 2x a week, and becomes stable on the first Tuesday of the next month. In the initial phase of the marketplace, when a lot is still changing and direct testing is required, latest makes more sense. Later stable makes more sense because then errors in the API are less likely.
The request URI for the “latest” API version is https://api.onoffice.de/api/latest/api.php
The request URI for the “stable” API version, which is updated monthly, is https://api.onoffice.de/api/stable/api.php
If you are using a live client, it is automatically redirected to the stable API version, regardless of the set API version.
If you are using a beta client, it will be automatically redirected to the latest API version, regardless of the set API version.
If you want your service to work with multilingual properties and function correctly, please note the following information when reading and writing multilingual properties: If your customer calls your service from a multilingual property, then in addition to the property ID
estateid the parameter
language is passed to you. You can then use
language to read the required values from a multilingual property via the API call “Read property” and write the required values back to multilingual properties via the API call “Edit property“.
estateid is specified in the API as
estatelanguage . Without specifying the parameter
estatelanguage would be written to the wrong language version of the property.
The API calls for the Marketplace can still change sometimes, especially in the early days. In the vast majority of cases, the changes remain downward compatible, e.g. new parameters are added. Please be prepared for this and build your interface accordingly flexible and fault tolerant.
This post is also available in: German