> 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/app-store-listing-requirements.md). # App Store Listing Requirements Requirements for accurate, complete, and customer-ready VARIO App Store listings. The App Store listing is the customer's primary source of information before deciding whether an app is relevant and suitable for their business. Every listing must therefore be complete, accurate, understandable, and representative of the app that has been submitted for review. {% hint style="info" %} The App Store listing is part of the App Store review. An app may be technically ready for publication but still require changes to its listing before VARIO approves it for release. {% endhint %} ### General listing quality The listing must allow a potential customer to understand, without contacting the App Provider first: * what the app does; * which problem it solves; * who it is intended for; * which VARIO processes or data it interacts with; * which important functionality is included; * what is required to use it; * whether additional services or accounts are required; * what the app costs; * where documentation and support are available. The listing must describe the app as it exists in the version submitted for publication. It must not rely on vague marketing statements instead of explaining the actual functionality. ### App name The app name should be short, recognizable, and suitable for display throughout the VARIO App Store. The name must: * identify the app clearly; * be consistent with the name used in the app and its documentation; * avoid misleading references to functionality that is not provided; * not imply that the app is developed by VARIO unless VARIO is the developer; * respect applicable trademark and naming rights. Avoid unnecessary additions such as: * version numbers; * marketing slogans; * excessive capitalization; * technical implementation names; * internal project names. Preferred: > PayPal > Channel Pilot Pro > DMS Upload-Link Avoid: > THE BEST PAYPAL INTEGRATION V2.4 – POWERED BY COMPANY XY ### Short description Every app requires a concise short description. The short description is used in App Store overviews, search results, and other compact listing contexts. It should explain the primary customer benefit in one sentence. A good short description normally answers: > What does this app enable me to do with VARIO? For example: > Synchronize articles, inventory, and orders automatically between VARIO Cloud and your marketplace. Avoid generic descriptions such as: > The perfect solution for your business. or: > A powerful integration with many useful features. The short description must describe actual functionality rather than general marketing claims. ### Main description The main description should explain the app from the customer's perspective. A recommended structure is: 1. the customer problem or use case; 2. how the app connects that process with VARIO; 3. the most important functionality; 4. the resulting customer benefit; 5. important prerequisites or limitations where relevant. The opening paragraphs should allow the reader to understand the app without first reading a detailed feature list. For example: > Connect your marketplace directly to VARIO Cloud. Product data, prices, inventory, and orders are synchronized automatically so that your team can manage the sales channel from the ERP instead of maintaining the same information in multiple systems. The description should then explain the most relevant functionality in more detail. ### Write for VARIO customers App Store copy should be understandable to the intended business user. Avoid unnecessary implementation terminology such as: * endpoint names; * internal API objects; * database tables; * internal queue names; * source code concepts unless the information is genuinely relevant to the customer's decision. Technical implementation details belong in the app documentation, not in the primary App Store description. Use the terminology customers see in VARIO Cloud wherever practical. ### Focus on actual customer outcomes Feature descriptions should explain what the customer can achieve with the functionality. Prefer: > Automatically import new marketplace orders into VARIO and create the corresponding customer and sales order. instead of: > Uses our new asynchronous REST integration architecture. Technical advantages may be mentioned where they produce a relevant customer benefit, but they should not replace a description of the actual functionality. ### Feature list The listing should contain a structured overview of the app's most important capabilities. Feature lists should: * focus on meaningful customer functionality; * use concise and understandable wording; * describe the current version of the app; * avoid repeating the same benefit in different words; * avoid listing insignificant implementation details as separate features. Where an app contains many functions, prioritize the capabilities that are most relevant to a customer's purchase decision. A feature list is not expected to replace the app documentation. ### Current functionality only Functionality described as available must be included in the version submitted for review. The listing must not present: * planned functionality; * prototypes; * internal development versions; * functionality requiring an unreleased app update as currently available. Future functionality may be mentioned separately if it is clearly identified as planned. For example: #### Planned * support for additional marketplace countries; * automated image synchronization. Planned functionality must not dominate the listing or create the impression that it is already available. {% hint style="warning" %} Do not use future functionality to make the current app appear more complete than it is. Customers must be able to distinguish clearly between what they can use today and what may become available later. {% endhint %} ### Prerequisites All material prerequisites for using the app must be disclosed in the listing. Depending on the app, this may include: * an account with an external service; * a specific plan or subscription with the external provider; * API access provided by the external service; * specific VARIO functionality; * required configuration; * supported countries or regions; * supported currencies; * supported marketplaces or platforms; * compatible hardware; * setup performed by the App Provider; * additional services that must be purchased separately. A prerequisite is material if a customer could reasonably purchase or install the app and then discover that the app cannot be used without it. {% hint style="warning" %} Mandatory prerequisites must not be hidden exclusively in documentation that the customer is expected to discover after purchasing the app. {% endhint %} ### External accounts Where an external account is required, the listing must clearly identify the external service. For example: > Requires an active PayPal Business account. or: > A Channel Pilot Pro subscription is required and is contracted separately with the provider. Where applicable, explain whether the customer: * needs an existing account; * can create an account during setup; * must obtain API access from the external provider; * requires a particular external subscription level. ### Additional costs All costs that are necessary to use the advertised functionality must be transparent. This includes relevant costs that are not charged through the VARIO App Store, such as: * subscriptions with external providers; * usage fees; * transaction fees; * mandatory setup services; * required third-party licenses. The listing does not need to reproduce the complete pricing terms of an external provider, but it must make clear that additional costs may arise. For example: > Additional fees from the shipping provider may apply depending on your contract. ### App Store price The price shown in the App Store must correspond to the commercial model agreed for the app. Where pricing depends on usage, packages, users, transactions, or another variable, the listing must explain the relevant pricing principle clearly enough for the customer to understand how charges may arise. Avoid descriptions such as: > From €19 if the customer cannot determine what changes the actual price. Where VARIO handles the complete pricing presentation separately, the descriptive text should not contradict the price information displayed by the App Store. ### Included and optional functionality If only part of the app's functionality is included in the displayed App Store price, this must be clear. For example, distinguish between: * functionality included in the base app; * optional modules; * additional external services; * separately chargeable implementation services. Customers must not discover after activation that a prominently advertised core function requires an undisclosed additional purchase. ### App status If the app is published with a special status such as **Beta** or **Coming soon**, the listing must accurately reflect that status. #### Beta A Beta listing should explain relevant limitations that customers need to understand before using the app productively. Do not use the Beta label as a substitute for describing known material limitations. #### Coming soon A Coming soon listing must make clear that the app is not yet available for productive installation. It may describe the planned purpose and expected functionality but must not present those features as already available. The quality requirements for these publication states are described in **App Quality and Publishing Readiness**. ### Developer information The listing must identify the App Provider responsible for the app. The provider name should use the company's recognizable legal or commercial name. Where the app is based on another company's platform or technology, the listing must not create ambiguity about who develops and operates the VARIO App. ### Category The app must be assigned to the category that best represents its primary purpose. Examples of App Store categories may include: * Online Shops; * Marketplaces; * Shipping; * Financial Accounting; * Payment Providers; * Industry and Specialized Solutions; * Other Solutions. The available categories may change as the VARIO App Store evolves. If an app fits multiple categories, the primary category should represent the use case most customers are likely to associate with the app. VARIO may adjust the category during the listing review to maintain a consistent App Store structure. ### App logo Every Public App must provide a suitable app logo or icon. The logo should: * clearly identify the app; * remain recognizable at small sizes; * use a high-quality source file; * avoid unnecessary surrounding whitespace; * not contain unreadably small text; * not use VARIO branding in a way that implies VARIO developed the app; * respect applicable trademark rights. A square source format is preferred where possible because the asset may be displayed in different App Store contexts. Use SVG or a high-resolution PNG where available. {% hint style="info" %} The logo should identify the product, not function as an advertisement. Avoid adding slogans, promotional claims, pricing, or badges directly into the logo asset. {% endhint %} ### Screenshots Apps with a customer-facing user interface should provide current screenshots that demonstrate the actual app. Screenshots are an important part of the listing and should help a potential customer understand the user experience before installing the app. Where practical, provide several screenshots showing different relevant parts of the app. A useful screenshot set might include: 1. the main app view; 2. an important workflow; 3. configuration or mapping; 4. a relevant result or status view. The exact number depends on the app. VARIO may request additional screenshots where the submitted material does not adequately represent the app. ### Screenshot quality Screenshots must: * show the current app version; * be sharp and readable; * use a consistent presentation; * focus on relevant functionality; * avoid unnecessary browser or desktop clutter; * not contain visible development tools or debug information; * not expose credentials, tokens, or confidential customer information. Where realistic data improves understanding, use suitable demonstration data instead of real customer data. Avoid screenshots that are almost entirely empty or do not show meaningful app functionality. ### Do not replace screenshots with marketing graphics Marketing illustrations may complement a listing but should not replace screenshots where the app has a meaningful user interface. Customers should be able to see what they will actually use. If an image is a conceptual illustration or mockup rather than a real screenshot, it should not create a misleading impression of the available product. ### Documentation Every Public App must provide customer documentation appropriate to its functionality. The documentation must be accessible through the resource link submitted for the listing. At minimum, the documentation should explain, where applicable: * prerequisites; * installation or initial setup; * connection to external services; * important configuration; * the primary workflows; * known relevant limitations; * troubleshooting; * how to obtain support. The documentation must correspond to the version of the app being published. {% hint style="info" %} The App Store listing explains **why a customer would use the app**. The app documentation explains **how the customer uses it**. Do not attempt to replace one with the other. {% endhint %} ### Documentation link The documentation link must lead directly to documentation for the app. Avoid linking only to: * the provider's homepage; * a generic product overview; * a contact form; * a sales landing page when the actual app documentation cannot be reached easily from there. Documentation must be accessible to customers who are entitled to use the app. If documentation requires authentication, VARIO must receive suitable access for the review. ### Privacy information The listing must provide the privacy information required for the app. The information and links submitted for publication must correspond to the app-specific privacy information agreed with VARIO. A generic company privacy policy is not sufficient if it does not describe the data processing relevant to the app. The actual technical behavior of the app must remain consistent with the submitted privacy information. See **Security and Privacy Review** for the corresponding review criteria. ### Support information Customers must have a clear way to obtain support for the app. The submitted support information should identify an appropriate support channel such as: * support email address; * support portal; * ticket system; * documented support contact. The contact must lead to a channel that is actively monitored by the App Provider. A personal employee email address should be avoided where support depends on the availability of one individual. ### Supported languages The listing must identify relevant language limitations where they may affect a customer's decision. If the app interface or documentation is available only in specific languages, this should be clear before purchase. Do not imply multilingual support merely because VARIO Cloud itself is available in additional languages. ### Supported regions Where the app is restricted to certain countries or regions, this must be disclosed. This is particularly relevant where functionality depends on: * local marketplaces; * shipping providers; * payment services; * accounting rules; * tax requirements; * country-specific APIs. For example: > Currently available for customers in Germany and Austria. ### Limitations Material limitations that are likely to influence a customer's decision must be stated clearly. Examples may include: * only one external account can be connected; * synchronization is one-directional; * historical data is not imported; * specific document types are not supported; * an external API does not provide certain information; * only selected countries are supported. The listing does not need to document every technical edge case. It must, however, disclose limitations that materially affect the advertised use case. ### Avoid misleading claims Claims in the App Store listing must be accurate and supportable. Avoid absolute statements such as: * `100% error-free`; * `guaranteed availability`; * `works with every marketplace`; * `fully automatic` unless the statement is genuinely accurate for the complete advertised scope. Where automation has defined exceptions or requires user intervention, the wording should represent this appropriately. ### Certifications and badges Certifications, partner levels, awards, security claims, or third-party badges may only be used where they actually apply to the app or App Provider and remain valid. The listing must not imply certification by VARIO beyond the publication and review status actually granted by VARIO. Third-party logos and certification marks may only be used where the App Provider has the right to use them. ### Customer references If the listing mentions customers, testimonials, case studies, or customer logos, the App Provider must have the necessary right to publish them. Customer information must not be used merely because the App Provider has access to it through the app. ### Links All links submitted for the listing must be: * reachable; * relevant to the app; * appropriate for customers; * maintained while the app remains published. Typical resource links may include: * app documentation; * support; * provider website; * relevant external service information. Links must not lead customers to unrelated or misleading content. ### Keep the listing current The App Provider must keep the App Store listing consistent with the current published version of the app. The listing should be reviewed whenever an update materially changes: * functionality; * prerequisites; * pricing; * supported platforms; * supported countries; * external dependencies; * documentation; * relevant limitations. If a previously advertised function is removed, the listing must be updated accordingly. The re-review requirements for app changes are described in **App Updates and Re-Review**. ### Submission completeness All information required for the App Store listing must be submitted before publication. A submission may be returned for completion if it is missing relevant material such as: * app description; * feature information; * logo; * screenshots; * documentation; * prerequisites; * pricing information; * privacy information; * support contact. {% hint style="warning" %} Do not submit placeholder content such as **“Information coming soon”**, temporary screenshots, or unfinished descriptions for a regular Public App release. The App Store listing should be publication-ready when it enters final review. {% endhint %} ### What VARIO reviews During the App Store listing review, VARIO may verify in particular whether: * the app name and branding clearly identify the product; * the short description communicates the primary customer benefit; * the main description explains the app and its use case; * advertised functionality matches the reviewed app; * planned functionality is clearly separated from available functionality; * material prerequisites are disclosed; * external accounts and additional costs are transparent; * pricing information is understandable and consistent; * app status is represented correctly; * category and developer information are appropriate; * the logo and screenshots are suitable for publication; * screenshots represent the actual app; * documentation is complete and accessible; * privacy and support information are available; * supported languages and regions are clear where relevant; * material limitations are disclosed; * claims are accurate and not misleading; * all submitted links are functional; * the complete listing is ready for publication. VARIO may request editorial, visual, or structural changes where necessary to maintain a consistent quality level across the VARIO App Store. --- # 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/app-store-listing-requirements.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.