> For the complete documentation index, see [llms.txt](https://developer.vario-software.de/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.vario-software.de/app-store-guidelines/app-requirements/technical-integration-and-app-lifecycle.md). # Technical Integration and App Lifecycle Technical integration and lifecycle requirements for VARIO App Store apps. A Public App must integrate with VARIO Cloud through the supported App mechanisms and remain in a consistent state throughout its complete lifecycle. This includes installation, configuration, regular operation, updates, uninstallation, and reinstallation. {% hint style="info" %} This page defines what VARIO expects during App Store review. It does not replace the technical implementation documentation. For implementation details, refer to the [VARIO Developer Docs](https://developer.vario-software.de/documentation/apps/introduction), including the [App Manifest](https://developer.vario-software.de/documentation/apps/app-manifest), [Authentication](https://developer.vario-software.de/documentation/apps/authentication), [UI Integration](https://developer.vario-software.de/documentation/apps/ui-integration), and [Webhooks](https://developer.vario-software.de/documentation/webhooks/introduction) documentation. {% endhint %} ### Use supported VARIO interfaces Apps must access VARIO Cloud only through interfaces and integration mechanisms documented and intended for App development. Depending on the use case, these may include: * the VARIO REST API; * VQL; * Webhooks; * App UI integration points; * App lifecycle endpoints; * other interfaces explicitly documented for App use. Apps must not rely on: * direct access to internal VARIO databases; * undocumented internal APIs or endpoints; * internal implementation details of VARIO Cloud; * bypassing authentication or authorization mechanisms; * behavior that is incidental and not part of a documented App interface. {% hint style="danger" %} Use of undocumented internal interfaces or circumvention of VARIO security or authorization mechanisms will prevent App Store approval. {% endhint %} If the required functionality is not available through a documented interface, the App Provider should contact VARIO Developer Support before implementing an alternative approach. ### App Manifest The App Manifest submitted for review must accurately describe the version of the app being reviewed. The manifest must contain the information required by the current [App Manifest specification](https://developer.vario-software.de/documentation/apps/app-manifest). In particular, the submitted manifest must be consistent with the actual app regarding: * app identity and version; * app URLs; * installation and uninstallation endpoints; * runtime manifest configuration; * required VARIO permissions; * app-specific authorization verbs; * UI integration points. The manifest must not contain obsolete configuration, unused integration points, or permissions that are no longer required by the submitted version. Temporary development URLs must not be used for a production App Store release. ### Version identification Each app version submitted to VARIO must be uniquely identifiable through its App Manifest. If an existing Public App is updated, the submitted version must allow VARIO to distinguish the new version from the previously approved version. The App Provider must provide a short summary of relevant changes as part of the review submission. The change summary should identify, where applicable: * new or changed functionality; * changes to VARIO permissions; * changes to data access; * changes to installation or uninstallation; * new external services or dependencies; * relevant changes to UI integrations. Requirements for determining whether an update requires another review are covered in **App Updates and Re-Review**. ### Reachable App endpoints All endpoints required by VARIO Cloud to install, operate, or uninstall the app must be reachable from VARIO Cloud. Endpoints used for an App Store release must: * use HTTPS; * use a valid TLS certificate; * be available under the URLs submitted for the app; * return controlled responses for expected error conditions. The app must not depend on a local development environment, temporary tunnel, developer workstation, or other infrastructure that is not appropriate for productive customer use. A dedicated review environment may be used if it represents the version intended for publication and allows VARIO to test the complete lifecycle of the app. ### Installation The installation process must establish a usable and consistent app installation for the respective VARIO Cloud tenant. The app must implement the installation lifecycle defined in the Developer Docs. Depending on the app, installation may include: * establishing the tenant-specific app connection; * securely storing the credentials required for subsequent API access; * creating app-specific configuration; * registering Webhooks; * initializing required app data; * registering app backends or other supported integration objects; * connecting an external account or service. After installation, the app must clearly be in one of the following states: * ready to use; * installed but requiring further configuration; * installation failed. The user must not be left with an installation that appears successful while required technical setup has failed. {% hint style="success" %} A successful installation should leave the app in a deterministic state: either it can be used immediately, or the user is clearly guided through the remaining configuration. {% endhint %} ### Additional configuration Some apps require configuration after the technical installation has completed. This is permitted. The app must clearly communicate: * which configuration is still required; * who needs to complete it; * where the configuration can be performed; * when the app is ready for productive use. Configuration required for the primary use case must not be hidden or left undocumented. If setup normally requires assistance from the App Provider, this must also be stated in the App Store listing. ### External accounts and services An app may depend on an external platform, service, account, API credential, license, or contract. Where this is the case, the user must be informed before purchasing or activating the app. The setup process must make it clear: * which external service is required; * whether a separate account is required; * whether the user must authenticate with the external service; * whether additional configuration is required outside VARIO Cloud. Additional costs and commercial prerequisites are covered separately in **App Store Listing Requirements**. ### Installation must be repeat-safe App lifecycle operations may be retried or invoked again after a failed attempt. The app must therefore avoid creating duplicate technical configuration when an installation step is executed more than once. For example, repeated installation must not unintentionally create: * duplicate Webhook subscriptions; * duplicate scheduled jobs; * duplicate app configuration; * duplicate backend registrations; * duplicate tenant records. Where an operation cannot safely be executed more than once, the app must detect the existing state and handle it in a controlled way. ### Webhooks and background processing Apps should use event-driven processing where VARIO provides an appropriate Webhook. High-frequency polling should be avoided when the same purpose can reasonably be achieved through Webhooks. Apps using background processing must: * respect documented platform limits; * handle temporary failures in a controlled way; * avoid uncontrolled retry loops; * prevent repeated processing from creating unintended duplicate business data; * provide sufficient processing status for relevant customer-facing operations. Implementation details for event-driven integrations are documented under [Webhooks](https://developer.vario-software.de/documentation/webhooks/introduction). Business-level requirements for duplicate prevention and data integrity are covered in **Permissions and Data Quality**. ### API usage API usage must be proportionate to the functionality provided by the app. Apps must not generate unnecessary load on VARIO Cloud. Where relevant, apps should: * request only the data required for the current process; * use appropriate filters and pagination; * process large data volumes in manageable batches; * respect documented rate limits; * avoid repeatedly requesting unchanged data; * use Webhooks where they are more appropriate than polling. Temporary API failures must be handled without creating uncontrolled request loops or inconsistent customer data. ### Uninstallation Uninstalling an app must reliably stop the app from operating for the affected VARIO Cloud tenant. The app must implement the uninstallation lifecycle defined in the Developer Docs. Where applicable, uninstallation must ensure that: * tenant-specific API access is no longer used; * credentials or tokens that must no longer be retained are removed or invalidated; * Webhook subscriptions belonging to the installation no longer trigger app processing; * scheduled or background jobs for the installation are stopped; * app-specific technical configuration is deactivated or cleaned up as appropriate. Uninstallation must not leave processes running that continue to access or modify the customer's VARIO data. {% hint style="warning" %} Uninstallation does not automatically mean that all business data created by the app should be deleted. The handling of customer data and VARIO business objects must follow the applicable Developer Docs, the app's documented behavior, and the relevant contractual and privacy requirements. {% endhint %} ### Reinstallation A customer must be able to reinstall an app after it has previously been uninstalled, unless the nature of the app requires a different process that has been agreed with VARIO. Reinstallation must not unintentionally reactivate: * outdated credentials; * invalid Webhook subscriptions; * obsolete configuration; * background jobs from the previous installation. If previous app data or configuration is intentionally restored, the resulting behavior must be predictable and documented. ### Updates and migrations App updates must not leave existing customer installations in an inconsistent state. Where an update requires changes to app-specific configuration, registered objects, Webhooks, or stored data, the app must provide a controlled migration path. Migrations must be designed so that: * they apply only to the intended tenant; * the current migration state can be determined; * successfully completed migration steps are not unintentionally repeated; * failures can be identified and investigated; * partially completed updates do not silently leave the app unusable. Where a migration changes customer-facing behavior, required permissions, or relevant data processing, the associated App Store listing and documentation must be updated as well. ### Technical errors during lifecycle operations Installation, configuration, migrations, and uninstallation must handle failures explicitly. The user must not receive a successful completion state when a required lifecycle operation has failed. Where a failure prevents normal use, the app should provide: * a clear error state; * an understandable explanation; * an appropriate next action; * a way for the App Provider to identify the technical cause. Sensitive technical details, credentials, tokens, or internal stack traces must not be exposed to ordinary users. ### Use of the VARIO App Framework The [VARIO App Framework](https://github.com/vario-software/vario-app-framework) and [VARIO App Demo](https://github.com/vario-software/vario-app-demo) provide reference implementations for common VARIO App patterns. Using the framework is recommended, but it is not mandatory unless explicitly required for a specific integration. An app using another technology stack must still provide an equivalent level of: * authentication; * tenant isolation; * lifecycle handling; * API integration; * error handling; * UI integration. The App Provider remains responsible for ensuring that its implementation complies with the current VARIO Developer Docs. ### What VARIO reviews During the technical integration review, VARIO may verify in particular whether: * only documented VARIO interfaces are used; * the App Manifest represents the submitted app correctly; * required endpoints are reachable; * installation completes successfully; * required post-installation configuration is understandable; * repeated installation does not create unintended duplicates; * the app can execute its primary VARIO integration successfully; * Webhooks and background processing behave predictably; * uninstallation stops tenant-specific app activity; * reinstallation results in a valid state; * updates and migrations do not compromise existing installations; * technical failures are handled in a controlled way. The review may include additional technical scenarios where required by the app's functionality or integration depth. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://developer.vario-software.de/app-store-guidelines/app-requirements/technical-integration-and-app-lifecycle.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.