> 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/review-process/submission-checklist.md). # Submission Checklist Use this checklist before submitting an app for App Store review. It is intended as a practical final check. The detailed requirements remain defined in the individual sections of the VARIO App Store Guidelines. {% hint style="info" %} Not every item applies to every app. Items marked **if applicable** only need to be completed where they are relevant to the app's functionality or business model. {% endhint %} ### Contractual prerequisites * [ ] A valid Framework Agreement with VARIO is in place. * [ ] The App Provider information is current. * [ ] A contact person for the App Store review has been designated. * [ ] The app-specific contractual information required for publication has been provided or is being coordinated with VARIO. * [ ] The App-Specific Agreement can be completed before publication. ### App readiness * [ ] The app is available as a working private VARIO Cloud App. * [ ] The primary customer use case is fully implemented. * [ ] The functionality advertised for publication is available in the submitted version. * [ ] No essential functionality contains placeholder or unfinished content. * [ ] The app can be tested without undocumented developer intervention. * [ ] Relevant limitations are known and documented. * [ ] The app version submitted for review is clearly identifiable. ### Installation and lifecycle * [ ] The app can be installed successfully in a VARIO Cloud tenant. * [ ] Required configuration after installation is clearly explained. * [ ] The app reaches a deterministic state after installation: either ready to use or clearly requiring further configuration. * [ ] Repeated installation does not unintentionally create duplicate technical configuration. * [ ] Relevant migrations have been tested. * [ ] Existing installations can be updated safely **if applicable**. * [ ] The app can be uninstalled successfully. * [ ] Uninstallation stops tenant-specific background activity and access. * [ ] Reinstallation has been tested **if applicable**. ### App Manifest * [ ] The App Manifest represents the version submitted for review. * [ ] App name and version information are correct. * [ ] Production URLs are correct and reachable. * [ ] Installation and uninstallation URLs are correct. * [ ] Required VARIO permissions are complete. * [ ] Unused VARIO permissions have been removed. * [ ] App-specific authorization verbs are current. * [ ] UI integration points are current. * [ ] Temporary development URLs or obsolete configuration have been removed. Refer to the [App Manifest documentation](https://developer.vario-software.de/documentation/apps/app-manifest) for the technical specification. ### VARIO permissions * [ ] Every requested VARIO permission is required by functionality available in the submitted version. * [ ] No permissions are requested only for planned future functionality. * [ ] A clear explanation can be provided for every requested permission. * [ ] Read, create, update, and delete access is limited to what the app actually needs. * [ ] Customer data is accessed only where required for the documented app purpose. ### App-specific authorization * [ ] Sensitive app functions are protected by appropriate authorization. * [ ] Authorization is enforced by the backend and not only by hiding UI elements. * [ ] Permission names and descriptions are understandable to VARIO administrators. * [ ] Users without the required permission receive an intentional and understandable experience. ### Tenant isolation * [ ] Tenant-specific credentials are stored separately. * [ ] Tenant-specific configuration is separated. * [ ] Customer data cannot be accessed across tenant boundaries. * [ ] Background jobs use the correct tenant context. * [ ] Webhook processing uses the correct tenant context. * [ ] External system credentials cannot be shared accidentally between tenants. {% hint style="danger" %} Cross-tenant access is a blocking issue for App Store publication. {% endhint %} ### Data quality * [ ] Data mappings preserve the intended business meaning. * [ ] Stable identifiers are used to match synchronized records. * [ ] Synchronization ownership is defined where data can change in multiple systems. * [ ] Repeated processing does not unintentionally create duplicate business records. * [ ] Webhook handlers can safely handle repeated delivery. * [ ] The app does not rely on asynchronous events arriving in a specific order. * [ ] Imports distinguish reliably between new and existing records. * [ ] Invalid external data is validated before it creates incorrect VARIO records. * [ ] Pagination and batch processing have been tested with realistic data volumes. * [ ] Partial processing failures are handled transparently. * [ ] Retry behavior does not create duplicate operations. * [ ] High-impact or destructive operations include appropriate safeguards. ### Webhooks and background processing * [ ] Webhooks are used where they are more appropriate than frequent polling. * [ ] Webhook endpoints are reachable and authenticated correctly. * [ ] Webhook processing is idempotent where duplicate delivery may occur. * [ ] Background jobs do not create uncontrolled retry loops. * [ ] Customer-relevant processes expose an understandable processing status. * [ ] Failed jobs can be identified. * [ ] A safe retry mechanism is available where appropriate. Refer to the [Webhooks documentation](https://developer.vario-software.de/documentation/webhooks/introduction) for implementation details. ### API usage * [ ] Only documented VARIO interfaces are used. * [ ] The app does not depend on undocumented internal APIs or implementation details. * [ ] API queries request only the data required for the process where practical. * [ ] Large datasets are processed using appropriate filtering, pagination, or batching. * [ ] Documented rate limits are respected. * [ ] Temporary API failures are handled in a controlled way. * [ ] API failures do not create uncontrolled request loops. ### User experience * [ ] The app appears complete and ready for productive use. * [ ] Navigation is understandable. * [ ] Actions use clear labels. * [ ] Forms identify required information. * [ ] Invalid input produces understandable validation messages. * [ ] User input is preserved after validation errors where practical. * [ ] Longer operations provide loading or processing feedback. * [ ] Important successful operations provide clear confirmation where necessary. * [ ] Empty states explain what the user can do next. * [ ] Customer-facing errors explain what failed and what action can be taken. * [ ] Technical stack traces or internal error details are not shown to ordinary users. * [ ] Partial failures are clearly distinguishable from complete success. * [ ] Destructive or high-impact actions provide appropriate confirmation. * [ ] Missing permissions are handled intentionally. * [ ] External authentication or account connections clearly identify the external service. * [ ] The app does not unnecessarily disrupt VARIO Cloud navigation or user workflows. ### Language and terminology * [ ] Customer-facing language is consistent. * [ ] VARIO terminology is used where appropriate. * [ ] The interface does not unnecessarily mix languages. * [ ] Supported interface languages are known. * [ ] Documentation languages are known. * [ ] Language limitations are disclosed in the App Store listing where relevant. ### Security * [ ] VARIO authentication is implemented according to the Developer Docs. * [ ] Authenticated backend functionality cannot be bypassed through the frontend. * [ ] VARIO credentials and secrets are stored securely. * [ ] External API credentials are stored securely. * [ ] Secrets are not exposed in frontend source code. * [ ] Secrets are not included in URLs or logs unnecessarily. * [ ] Production endpoints use HTTPS with valid TLS certificates. * [ ] User and external input is validated server-side. * [ ] Production systems do not expose unnecessary debug or development functionality. * [ ] Administrative interfaces are appropriately protected. * [ ] Relevant dependencies are actively maintained. * [ ] Known relevant security vulnerabilities have been addressed. * [ ] Production logs are restricted to authorized personnel. ### Logging * [ ] Logs do not contain passwords. * [ ] Logs do not contain access or refresh tokens. * [ ] Logs do not contain `offlineToken` values. * [ ] Logs do not contain API keys or other secrets. * [ ] Sensitive customer information is masked where appropriate. * [ ] Log information is sufficient to investigate failed customer processes without unnecessarily exposing confidential data. ### Privacy and data processing * [ ] The actual data processing of the app is understood and documented. * [ ] The app processes only data required for its documented purpose. * [ ] Categories of VARIO data processed by the app are known. * [ ] External recipients of customer data are known. * [ ] Relevant service providers and subprocessors are known **if applicable**. * [ ] Data storage and processing locations are known where relevant. * [ ] Data retention behavior is defined where the app stores customer data. * [ ] Uninstallation stops future unauthorized VARIO access. * [ ] The privacy information provided for the app matches the actual technical behavior. * [ ] A new external service has not been introduced without updating the relevant information. ### External services * [ ] All external services required for the primary use case are operational. * [ ] Required external accounts are known. * [ ] Required external subscription levels are known **if applicable**. * [ ] Required API access from external providers is known **if applicable**. * [ ] External prerequisites are disclosed in the App Store listing. * [ ] Relevant additional third-party costs are disclosed. * [ ] VARIO can access an appropriate test or sandbox environment for review. ### App Store name and description * [ ] The app name clearly identifies the product. * [ ] The app name is consistent across the app, documentation, and submission. * [ ] The short description explains the primary customer benefit. * [ ] The main description explains the actual use case. * [ ] The listing describes the app from the customer's perspective. * [ ] Marketing claims accurately represent the available functionality. * [ ] Planned functionality is clearly separated from functionality available today. * [ ] Material limitations are disclosed. * [ ] The listing does not imply that VARIO developed the app unless VARIO is actually the developer. ### Features and prerequisites * [ ] The most important customer-facing features are listed. * [ ] Every advertised core feature is available in the submitted version. * [ ] Mandatory external accounts are disclosed. * [ ] Mandatory configuration requirements are disclosed. * [ ] Required VARIO functionality is disclosed **if applicable**. * [ ] Supported countries or regions are disclosed where relevant. * [ ] Supported external platforms are disclosed. * [ ] Required setup services are disclosed **if applicable**. * [ ] Important functional limitations are disclosed. ### Pricing * [ ] The submitted pricing information matches the agreed commercial model. * [ ] Customers can understand what the displayed price includes. * [ ] Usage-based or variable pricing is explained where applicable. * [ ] Mandatory additional third-party costs are disclosed. * [ ] Optional paid functionality is distinguishable from included functionality. * [ ] Mandatory implementation services are disclosed **if applicable**. ### App logo * [ ] A current app logo has been provided. * [ ] The logo is recognizable at small sizes. * [ ] The source file has sufficient quality. * [ ] The asset does not contain unnecessary promotional text. * [ ] The logo does not misleadingly imply VARIO ownership. * [ ] The App Provider has the right to use the logo and included trademarks. ### Screenshots * [ ] Current screenshots have been provided for apps with a customer-facing UI. * [ ] Screenshots show meaningful functionality. * [ ] The primary app experience is represented. * [ ] Important workflows or configuration areas are represented where useful. * [ ] Screenshots are sharp and readable. * [ ] No development tools or debug information are visible. * [ ] No credentials or secrets are visible. * [ ] No confidential customer information is visible. * [ ] Screenshots represent the actual app and are not misleading mockups. ### Documentation * [ ] Customer documentation is available. * [ ] The documentation link leads directly to the relevant app documentation. * [ ] Prerequisites are documented. * [ ] Initial setup is documented. * [ ] External account connection is documented **if applicable**. * [ ] Important configuration is documented. * [ ] The primary workflows are documented. * [ ] Relevant limitations are documented. * [ ] Troubleshooting information is available. * [ ] Support information is available. * [ ] Documentation corresponds to the version submitted for review. * [ ] VARIO can access the documentation during review. ### Support * [ ] A current support channel has been provided. * [ ] The support channel is actively monitored. * [ ] The support contact is suitable for long-term customer use. * [ ] Customers can determine where to obtain help. * [ ] The submitted support information is consistent with the App Store listing and documentation. ### Review environment * [ ] VARIO can access the app version intended for publication. * [ ] The environment is available independently of a developer's workstation. * [ ] The environment does not depend on a temporary development tunnel. * [ ] Relevant external integrations are available. * [ ] Suitable demonstration data is available. * [ ] The environment can be used to test the primary workflow. * [ ] Relevant error scenarios can be reproduced where necessary. ### Review credentials * [ ] Dedicated review credentials have been prepared where required. * [ ] Review credentials provide only the access needed for testing. * [ ] Production administrator credentials are avoided where possible. * [ ] Real customer credentials are not used unnecessarily. * [ ] Credentials will be transferred to VARIO through an appropriate secure channel. * [ ] Credentials will remain valid throughout the review. ### Review Guide * [ ] A short Review Guide has been prepared. * [ ] The Review Guide explains how to access the app. * [ ] Required configuration is explained. * [ ] Required test credentials are identified. * [ ] The primary workflow is described step by step. * [ ] The expected result is described. * [ ] Relevant external system actions are included. * [ ] Special scenarios VARIO should verify are identified. * [ ] The guide can be followed without undocumented assistance. Use the **Review Guide Template** under Submission Resources as the recommended structure. ### Final consistency check Before submitting, compare the following sources one final time: * [ ] App functionality; * [ ] App Manifest; * [ ] requested VARIO permissions; * [ ] App Store listing; * [ ] screenshots; * [ ] documentation; * [ ] privacy information; * [ ] pricing and prerequisites; * [ ] Review Guide. They must describe the same current app version and must not materially contradict one another. ### Ready to submit Your app is ready to enter the App Store review when: * [ ] the primary use case is production-ready; * [ ] all required submission information is complete; * [ ] VARIO can review the app independently; * [ ] no known blocking security or data-integrity issue remains; * [ ] the App Store listing is publication-ready. Submit the App Store information through the [App Store submission form](https://www.vario-software.de/partner-app-listing/). {% hint style="success" %} A complete submission significantly reduces unnecessary review cycles. The goal is that VARIO can understand, install, test, and evaluate the app without first having to request missing basic information. {% endhint %} --- # 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/review-process/submission-checklist.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.