> 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/app-listing-template.md).

# App Listing Template

Template for preparing complete, customer-ready information for a VARIO App Store listing.

Use this template to prepare the information required for a high-quality VARIO App Store listing.

Replace all placeholder text with information about your app before submitting it to VARIO.

{% hint style="info" %}
The App Store listing should be written for potential customers, not for the VARIO review team.

Technical implementation details that customers do not need for their purchase decision belong in your app documentation or Review Guide instead.
{% endhint %}

### App identification

#### App name

**\[APP NAME]**

Use the same product name that appears in the app and its documentation.

Keep the name short and recognizable.

Do not include:

* version numbers;
* marketing slogans;
* unnecessary technical terms;
* internal project names.

#### App Provider

**\[COMPANY / APP PROVIDER NAME]**

Enter the company responsible for developing and operating the app.

#### App version submitted for review

**\[VERSION]**

Example:

> 1.0.0

This information is used for review and does not necessarily need to appear prominently in the public App Store listing.

#### App category

**\[CATEGORY]**

Select the category that best represents the app's primary purpose.

Examples may include:

* Online Shops;
* Marketplaces;
* Shipping;
* Financial Accounting;
* Payment Providers;
* Industry and Specialized Solutions;
* Other Solutions.

VARIO may adjust the category during the listing review.

#### Publication status

**\[GENERAL AVAILABILITY / BETA / COMING SOON]**

For a regular Public App, use:

> General Availability

Use **Beta** or **Coming soon** only if this publication status has been coordinated with VARIO.

***

### Short description

**Recommended length: one concise sentence**

The short description should explain the primary customer benefit of the app.

Complete the following sentence:

> **\[APP NAME] enables VARIO Cloud users to \[PRIMARY CUSTOMER OUTCOME].**

Example:

> Synchronize articles, inventory, and orders automatically between VARIO Cloud and your marketplace.

Your short description:

> **\[SHORT DESCRIPTION]**

{% hint style="warning" %}
Avoid generic marketing language such as **“the perfect solution for your business”**.

A customer should understand what the app actually does from this sentence alone.
{% endhint %}

***

### Main description

The main description should explain the app from the customer's perspective.

A useful structure is:

1. What problem does the app solve?
2. How does it connect with VARIO Cloud?
3. What are the most important capabilities?
4. What result does the customer achieve?

#### Customer problem

Describe the process or problem the app addresses.

> **\[DESCRIBE THE CUSTOMER PROBLEM IN 2–4 SENTENCES]**

Example:

> Managing orders and product data separately in an ERP and a marketplace creates duplicate work and increases the risk of inconsistent information.

#### How the app helps

Explain what the app does and how VARIO Cloud is involved.

> **\[DESCRIBE HOW THE APP SOLVES THE PROBLEM]**

Example:

> The app connects your marketplace directly with VARIO Cloud. Product information, inventory, and orders can be exchanged automatically between both systems.

#### Customer outcome

Explain the practical result for the customer.

> **\[DESCRIBE THE PRIMARY CUSTOMER BENEFIT]**

Example:

> Your team can manage the relevant marketplace processes from VARIO instead of maintaining the same information manually in multiple systems.

***

### Key features

List the most important functionality available in the version submitted for publication.

Focus on meaningful customer capabilities rather than technical implementation details.

Recommended: **3–8 key features**.

#### Feature 1

**\[FEATURE NAME]**

\[Explain what the customer can do and why it is useful.]

#### Feature 2

**\[FEATURE NAME]**

\[Explain what the customer can do and why it is useful.]

#### Feature 3

**\[FEATURE NAME]**

\[Explain what the customer can do and why it is useful.]

#### Additional features

Add further features only where they are relevant to the customer's purchase decision.

* **\[FEATURE]** — \[SHORT EXPLANATION]
* **\[FEATURE]** — \[SHORT EXPLANATION]
* **\[FEATURE]** — \[SHORT EXPLANATION]

{% hint style="info" %}
Describe outcomes rather than implementation.

Prefer:

> Automatically import marketplace orders into VARIO.

Instead of:

> Uses asynchronous API processing and Webhooks.
> {% endhint %}

***

### Typical workflow

Describe the normal customer workflow in a few simple steps.

This helps potential customers understand how the app fits into their daily work.

Example:

1. Connect your marketplace account.
2. Configure the synchronization settings.
3. Transfer articles and inventory from VARIO.
4. Import new marketplace orders automatically.
5. Monitor synchronization results in the app.

Your workflow:

1. **\[STEP 1]**
2. **\[STEP 2]**
3. **\[STEP 3]**
4. **\[STEP 4]**
5. **\[STEP 5 — IF APPLICABLE]**

Keep this section focused on the business workflow. Detailed setup instructions belong in the app documentation.

***

### Prerequisites

List everything a customer needs before the app can be used.

#### VARIO requirements

**\[NONE / DESCRIBE REQUIRED VARIO FUNCTIONALITY]**

Examples:

* specific VARIO functionality;
* particular configuration;
* another required VARIO app or module.

If there are no special VARIO prerequisites, state:

> No additional VARIO prerequisites beyond an active VARIO Cloud environment.

#### External account

**\[NONE / REQUIRED EXTERNAL ACCOUNT]**

Example:

> An active PayPal Business account is required.

or:

> A Channel Pilot Pro account is required.

#### External subscription or plan

**\[NONE / DESCRIBE REQUIRED PLAN]**

Example:

> API access must be included in the customer's external provider subscription.

#### Setup requirements

**\[NONE / DESCRIBE REQUIRED SETUP]**

Explain whether:

* the customer can configure the app independently;
* the App Provider must perform setup;
* additional onboarding is required.

Example:

> Initial configuration can be completed by the customer directly in the app.

or:

> Initial setup is performed by the App Provider and is required before the app can be used.

***

### Supported systems and platforms

List the external systems, platforms, or services supported by the app.

#### Supported platforms

* **\[PLATFORM / SERVICE]**
* **\[PLATFORM / SERVICE]**
* **\[PLATFORM / SERVICE]**

If only specific versions, account types, or editions are supported, state this clearly.

***

### Supported countries and regions

**\[GLOBAL / LIST SUPPORTED COUNTRIES OR REGIONS]**

Example:

> Available for customers in Germany and Austria.

If the app is not region-specific, state:

> No specific regional restriction.

***

### Supported languages

#### App interface

* **\[LANGUAGE]**
* **\[LANGUAGE]**

#### Documentation

* **\[LANGUAGE]**
* **\[LANGUAGE]**

Example:

> App interface: German and English\
> Documentation: German and English

***

### Synchronization and data flow

For integration apps, briefly explain the primary direction in which data moves.

#### From VARIO to the external system

**\[DESCRIBE DATA TRANSFER OR WRITE "NOT APPLICABLE"]**

Example:

> Articles, prices, and inventory are transferred from VARIO Cloud to the marketplace.

#### From the external system to VARIO

**\[DESCRIBE DATA TRANSFER OR WRITE "NOT APPLICABLE"]**

Example:

> Marketplace orders are imported into VARIO Cloud.

#### Synchronization frequency

**\[REAL-TIME / EVENT-DRIVEN / SCHEDULED / MANUAL / OTHER]**

Example:

> Orders are imported automatically. Product and inventory updates are processed event-driven.

Do not make claims such as **“real-time”** unless the app actually provides this behavior.

***

### Important limitations

Describe limitations that could materially influence a customer's purchase decision.

Examples include:

* synchronization is one-directional;
* historical records are not imported;
* only selected document types are supported;
* only one external account can be connected;
* some countries are not supported;
* particular data cannot be transferred because the external API does not provide it.

Your limitations:

* **\[LIMITATION]**
* **\[LIMITATION]**
* **\[LIMITATION]**

If there are no material limitations beyond the normal product scope, state:

> No additional material limitations.

{% hint style="warning" %}
Do not hide a material limitation in technical documentation if a customer would reasonably expect to know it before purchasing the app.
{% endhint %}

***

### Pricing

#### App Store price

**\[PRICE / PRICING MODEL]**

Example:

> €29.90 per month

or:

> €0.05 per processed transaction

or:

> Pricing depends on the selected package.

#### What is included

Describe what the App Store price includes.

> **\[DESCRIBE INCLUDED FUNCTIONALITY OR USAGE]**

#### Additional App Provider costs

**\[NONE / DESCRIBE ADDITIONAL COSTS]**

Example:

> A one-time setup fee is charged by the App Provider.

#### Third-party costs

**\[NONE / DESCRIBE THIRD-PARTY COSTS]**

Example:

> Marketplace fees are charged separately by the marketplace provider.

or:

> An active subscription with the external provider is required and is not included in the VARIO App Store price.

{% hint style="info" %}
A customer should be able to understand which costs are charged through the VARIO App Store and which costs may arise separately.
{% endhint %}

***

### App logo

Provide the current logo for the app.

#### Recommended asset

* square format where possible;
* SVG preferred or high-resolution PNG;
* recognizable at small sizes;
* no unnecessary promotional text;
* no pricing or marketing badges.

**File:** \[APP LOGO FILE]

***

### Screenshots

Provide screenshots of the actual app version submitted for review.

Recommended: **3–5 meaningful screenshots** for apps with a customer-facing interface.

#### Screenshot 1 — Main app view

**File:** \[SCREENSHOT]

**Caption:**

> \[SHORT DESCRIPTION OF WHAT THE CUSTOMER SEES]

#### Screenshot 2 — Primary workflow

**File:** \[SCREENSHOT]

**Caption:**

> \[SHORT DESCRIPTION]

#### Screenshot 3 — Configuration or integration

**File:** \[SCREENSHOT]

**Caption:**

> \[SHORT DESCRIPTION]

#### Screenshot 4 — Result or processing status

**File:** \[SCREENSHOT — OPTIONAL]

**Caption:**

> \[SHORT DESCRIPTION]

#### Screenshot 5 — Additional relevant functionality

**File:** \[SCREENSHOT — OPTIONAL]

**Caption:**

> \[SHORT DESCRIPTION]

Screenshots should use suitable demonstration data and must not expose customer credentials, secrets, or confidential information.

***

### Documentation

#### Documentation URL

**\[DIRECT URL TO APP DOCUMENTATION]**

The link should lead directly to documentation for this app.

#### Documentation covers

Confirm that the documentation includes, where applicable:

* [ ] prerequisites;
* [ ] initial setup;
* [ ] external account connection;
* [ ] configuration;
* [ ] primary workflows;
* [ ] relevant limitations;
* [ ] troubleshooting;
* [ ] support information.

***

### Privacy information

#### App-specific privacy information

**\[URL OR REFERENCE REQUIRED FOR THE APP]**

The privacy information must correspond to the actual data processing performed by the app.

Where the app-specific privacy information forms part of the App-Specific Agreement or another document coordinated with VARIO, provide the corresponding reference as requested by VARIO.

#### General provider privacy policy

**\[URL — IF APPLICABLE]**

A general company privacy policy may be provided in addition to the app-specific information.

It must not be used as a substitute where app-specific data processing requires more detailed information.

***

### Support

#### Support channel

**\[SUPPORT EMAIL / SUPPORT PORTAL / TICKET SYSTEM]**

Example:

> <support@example.com>

or:

> <https://support.example.com/>

#### Support documentation

**\[URL — IF DIFFERENT FROM GENERAL DOCUMENTATION]**

#### Customer-facing support description

> **\[SHORT DESCRIPTION OF HOW CUSTOMERS RECEIVE SUPPORT]**

Example:

> For questions about setup and operation of the app, contact our support team through the support portal.

***

### App Provider website

**\[URL]**

Use the company's official website or a relevant product page.

***

### Optional additional information

Use this section only where the information genuinely helps a customer understand or evaluate the app.

Possible content includes:

* a product video;
* a relevant case study;
* supported industry scenarios;
* additional onboarding information;
* a link to the external platform;
* a relevant certification.

#### Additional resource

**Title:** \[RESOURCE TITLE]

**URL:** \[URL]

**Description:** \[SHORT DESCRIPTION]

Do not add promotional resources that are unrelated to the app.

***

### Review-only information

The following information helps VARIO review the app but is not intended as primary App Store marketing content.

#### App identifier

**\[APP IDENTIFIER]**

#### Review version

**\[VERSION]**

#### Review contact

**Name:** \[NAME]

**Email:** \[EMAIL]

**Company:** \[COMPANY]

#### Primary review scenario

Briefly describe the most important workflow VARIO should test.

> **\[PRIMARY REVIEW SCENARIO]**

A complete step-by-step description should be provided in the **Review Guide**.

#### Required VARIO permissions

List the permissions requested by the app and briefly explain their purpose.

| Permission        | Purpose                            |
| ----------------- | ---------------------------------- |
| `[RESOURCE:VERB]` | \[WHY THIS PERMISSION IS REQUIRED] |
| `[RESOURCE:VERB]` | \[WHY THIS PERMISSION IS REQUIRED] |
| `[RESOURCE:VERB]` | \[WHY THIS PERMISSION IS REQUIRED] |

#### External systems involved in review

* **\[SYSTEM]** — \[PURPOSE]
* **\[SYSTEM]** — \[PURPOSE]

#### Special review notes

> **\[ANY INFORMATION VARIO SHOULD KNOW BEFORE STARTING THE REVIEW]**

If there are no special considerations, state:

> None.

***

### Final check

Before submitting the listing, confirm that:

* [ ] the app name is final;
* [ ] the short description explains the customer benefit;
* [ ] the main description describes the actual app;
* [ ] all advertised functionality is available;
* [ ] material prerequisites are disclosed;
* [ ] additional costs are transparent;
* [ ] supported languages and regions are correct;
* [ ] material limitations are disclosed;
* [ ] logo and screenshots are current;
* [ ] documentation is accessible;
* [ ] privacy information is current;
* [ ] support information is current;
* [ ] all links work;
* [ ] the listing matches the version submitted for review.

{% hint style="success" %}
A good App Store listing should answer the customer's most important questions before they need to contact either VARIO or the App Provider:

**What does the app do? What do I need? What does it cost? What are the limitations? And where do I get help?**
{% endhint %}

Submit the final App Store information through the [App Store submission form](https://www.vario-software.de/partner-app-listing/).


---

# 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/app-listing-template.md?ask=<question>&goal=<endgoal>
```

`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.
