> 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/overview.md). # Overview Requirements for apps submitted for publication in the VARIO App Store. ### Purpose These Guidelines define the quality, implementation, submission, and review criteria that apps must meet to be published and remain available in the VARIO App Store. They are intended to help App Providers: * prepare their app for review; * understand what VARIO evaluates during the review; * create a complete and accurate App Store listing; * identify which changes may require another review. These Guidelines do not replace or repeat the legal, commercial, or technical provisions contained in the applicable agreements and technical documentation. ### Contractual prerequisites Before an app can be submitted for review, the App Provider must have entered into a valid **VARIO App-Store-Rahmenvertrag**, referred to in these Guidelines as the **Framework Agreement**. Before an app can be published in the VARIO App Store, an app-specific **Einzelvereinbarung**, referred to in these Guidelines as the **App-Specific Agreement**, must also be in place. {% hint style="warning" %} **Important:** Contracting, app submission, review, and publication are separate steps. Signing the Framework Agreement or an App-Specific Agreement does not, by itself, constitute approval of a specific app for publication. {% endhint %} An app will only be published after: * all required app and listing information has been submitted; * the app can be reviewed under realistic conditions; * the app meets the applicable requirements; * VARIO has completed the review and approved the app for publication. ### How the documents work together The documents and resources governing the VARIO App Store serve different purposes: #### Framework Agreement The Framework Agreement governs the general legal and commercial relationship between VARIO and the App Provider. #### App-Specific Agreement The App-Specific Agreement contains the provisions and information applicable to a specific app. #### VARIO Developer Docs The Developer Docs describe the technical implementation of VARIO Cloud apps, including APIs, authentication, app manifests, permissions, webhooks, and available integration points. #### App Store Guidelines These Guidelines describe the quality, implementation, listing, and review criteria used by VARIO when assessing an app. Capitalized terms used but not defined in these Guidelines have the meaning assigned to them in the Framework Agreement or the applicable App-Specific Agreement. ### Scope These Guidelines apply to all apps submitted for publication in the VARIO App Store. Unless stated otherwise, the requirements apply to: * the initial app submission; * subsequent app versions and updates; * the App Store listing; * the documentation and review materials; * the app while it remains available through the VARIO App Store. ### Review principles VARIO assesses apps based on the following principles: #### Useful and ready for production The app provides a clear benefit for VARIO Cloud users and its core use case is fully functional. #### Accurate and transparent The app, its listing, and its documentation accurately describe the available functionality, requirements, costs, and limitations. #### Properly integrated The app uses the documented VARIO interfaces and integration mechanisms and behaves reliably throughout installation, use, updates, and uninstallation. #### Proportionate access The app requests only the permissions and data access required for its actual functionality. #### Understandable to users The app provides clear navigation, status information, error messages, and instructions for its intended users. #### Reviewable by VARIO VARIO receives all information, test access, documentation, and instructions required to review the app without relying on undocumented assistance. ### Requirement levels The following terms are used throughout these Guidelines: * **Must** or **must not** indicates a mandatory requirement for approval. * **Should** or **should not** indicates a recommended approach. A different implementation may be accepted if it provides an equivalent level of quality, usability, and reliability. * **May** indicates an optional approach or a decision that depends on the app and its use case. Examples are provided to explain requirements. They are not exhaustive and do not limit VARIO's ability to assess comparable situations. ### Development resources The technical implementation of VARIO Cloud apps is documented separately in the VARIO Developer Docs. * [VARIO Cloud Developer Docs](https://developer.vario-software.de/) * [VARIO App Framework](https://github.com/vario-software/vario-app-framework) * [VARIO App Demo](https://github.com/vario-software/vario-app-demo) * [Submit App Store listing information](https://www.vario-software.de/partner-app-listing/) The Framework Agreement and the applicable App-Specific Agreement are provided separately by VARIO. --- # 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 by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://developer.vario-software.de/app-store-guidelines/overview.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. 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.