What is an EPOS Module

EPOS’s own functionality - products, sales, promotions, reports, and everything else in Back Office and Point of Sale - is built as a set of internal modules. This page explains what that means, mainly so it’s clear why it’s not the same thing as a public plugin system - see Plugins for that distinction.

An EPOS module is part of the codebase

A module is source code that lives in EPOS’s own repository, is reviewed like any other change to the product, and is built and deployed together with EPOS itself - not installed separately, not fetched at runtime, not sandboxed from the rest of the system. When EPOS ships a new version, every module ships with it, as one deployment.

This is fundamentally different from a plugin architecture, where a third party’s code is installed into a running system independently of the core product’s own release cycle. EPOS doesn’t have that today - see Plugins.

Why this distinction matters to you

If you’re integrating with EPOS as an external system, none of this affects you directly - you use the /v1 API regardless of how EPOS is built internally. This section exists because “module” and “plugin” get used loosely in conversations about extending EPOS, and this documentation wants to be precise: modules are internal, reviewed, and shipped with EPOS; plugins, as a concept of independently-installable third-party code, don’t exist in EPOS today.

What a module typically contains

At a high level (see Bundled Module Development for more): a data model, a service layer implementing business rules, an API surface (internal, not necessarily anything exposed under /v1), permission checks, and often a Back Office and/or POS UI surface. This is architectural background, not a specification you’d build against externally.