Orbito for AI agents

This track is written for coding agents (Claude Code, Codex, OpenCode) and for developers who work with one. It is short on purpose: read it top to bottom once, then use the cheatsheet while you write code.

What Orbito is

Orbito is a multi-tenant SaaS platform for running a company: orders, shipping, invoicing, integrations with marketplaces and carriers. Every company (a tenant) uses the same modules, with its data fully isolated from other companies.

The platform itself is a small core. Everything a company works with day to day is a module:

• A module is a standalone Node.js application that runs in its own Docker container. It has no direct network access; outgoing HTTP goes through Core.fetch, which the core proxies to domains the company admin has approved.
• A company installs a module and gets an instance. Each instance has its own container, its own configuration and its own MongoDB collections. A module that allows it ("singleton": false) can be installed several times in one company, for example once per web shop.
• A module talks to the core only through the SDK @orbito/api-lib, currently 4.3.0. The SDK registers methods, hooks, pages, configuration blocks and automation actions, and gives access to the database, config store, files, problems and history.
• A module never ships front-end code. Its screens are OVE views: declarative YAML or JSON trees (cards, tables, forms, modals, actions) that the Orbito front end renders. A view calls module methods over REST; the module answers with data.
• Modules are published to the module registry modules.orbito.pl with the omm CLI (Orbito Modules Manager). The registry builds the Docker image; companies install the module from the marketplace.
• One Orbito account logs in to the panel, the registry and omm. A module belongs to a namespace (a team: an owner and members), so its code is <namespace>/<slug>, for example acme/hello. Unreleased modules and drafts are visible only to namespace members and to companies granted access.

Modules cooperate in two ways: a direct call (Core.callModule) when one module needs another specific module, and hooks (Core.execHook / Core.registerHook) when any number of modules may answer.

How to use these docs as an agent

1. Read Module anatomy to know which files a module needs.
2. Follow The build loop. It lists every omm command from an empty directory to a released version, and says which steps need the human.
3. Copy patterns from the cheatsheet. Every snippet there runs against SDK 4.3.0.
4. Start from the example module acme/hello when you need a working baseline.
5. Read Company automations when the human asks for an automation or your module registers triggers and actions: it composes, validates and enables a company automation with omm automation.

The full reference is in Polish: SDK API, OVE views, module communication, deployment and omm. Read it when this track is not enough. Where this track and the Polish pages disagree, this track follows the SDK source and wins.