> 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/documentation/fundamentals/introduction.md).

# Introduction

Concepts that apply to every integration: tenants, VQL, custom fields, webhooks and app backends.

Universal concepts and core mechanisms that apply across the entire VARIO Cloud ecosystem — regardless of whether you are building a shop integration, a logistics connector, another type of app, or working directly with the API.

These guides cover the foundational building blocks every developer should understand. They are equally relevant for full app developers and for API-only users, as the underlying concepts, data structures, and system behavior remain the same across all integration approaches.

## In this section

| Page                                                          | What it covers                                                                      |
| ------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| [Custom Fields](/documentation/fundamentals/custom-fields.md) | Attaching your own fields to ERP entities — articles, accounts, documents, and more |
| [VQL](/documentation/fundamentals/vql.md)                     | The query language used to read and filter data across the whole ERP                |

## Concepts you will meet everywhere

### Tenants

Every VARIO Cloud installation is a **tenant**, reachable at its own subdomain. Your API base URL is derived from it (`https://{subdomain}.vario.cloud/api/vario`), and all data is scoped to that tenant. An integration that serves several customers talks to several tenants, each with its own credentials.

→ [REST API Introduction](/documentation/rest-api/introduction.md) explains how to build the base URL.

### Reading data: VQL

Most read access goes through **VQL** (VARIO Query Language), a SQL-like language that works across every entity — articles, accounts, documents, CRM activities. Instead of one endpoint per query, you send a statement and get rows back. VQL also handles filtering, sorting, and pagination.

→ [VQL](/documentation/fundamentals/vql.md)

### Extending the data model: Custom Fields

You cannot add columns to ERP tables, but you can attach **Custom Fields** to entities. They are the standard way for an integration to store its own data — external reference IDs, sync state, mapping information — directly on ERP records, and they are queryable from VQL.

→ [Custom Fields](/documentation/fundamentals/custom-fields.md)

### Reacting to change: Webhooks

Rather than polling, register a **webhook** and let the ERP notify your integration when data changes. Webhooks are also how scheduled work is triggered for apps.

→ [Webhooks](/documentation/webhooks/introduction.md)

### Domain backends

For some domains, an app does not just read and write data — it takes over a **role** in the ERP. It registers a typed *backend* during installation, and the ERP then routes work in that domain to the app:

| Domain                        | What the app registers              |
| ----------------------------- | ----------------------------------- |
| Online shops and marketplaces | A sales channel backend             |
| Shipping                      | A **carrier type** (`Versendertyp`) |
| Banking                       | A bank backend                      |
| Financial accounting          | A finance backend                   |
| POS payment methods           | A POS payment backend               |

Each of these is tagged with the app's identifier and marked as app-provided, so the ERP knows which app is responsible.

{% hint style="info" %}
Note the naming: for shipping there is no "carrier backend". The **carrier type** plays that role — it carries the app identifier and the callback URLs, while the actual carriers (`Versender`) are master data the customer creates on top of it.
{% endhint %}

→ [Core Concepts](https://developer.vario-software.de/core-concepts) covers each domain on a single page.

### Running logic inside the ERP

Not every extension needs an external service. **Scripting** runs server-side JavaScript directly in the ERP — for validation, enrichment, and automation with no network latency and no deployment pipeline.

→ [Scripting](/documentation/scripting/introduction.md)


---

# 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/documentation/fundamentals/introduction.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.