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	Attaching your own fields to ERP entities — articles, accounts, documents, and more
VQL	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 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

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

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

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.

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.

→ 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