# What is an extension An extension is a **manifest plus, optionally, code**. The manifest ([reference](/reference/manifest)) declares everything the platform hosts for it — and the platform hosts almost all of it *declaratively*, with no extension code involved: - **Identity**: `id` (`vendor.name`), `version`, `publisher`, Turkish label and description. - **Role**: a provider kind — payment, shipping, cargo, einvoice, channel, messaging, reporting — with kind-specific contract fields (a payment extension declares its `settlement`; a shipping extension declares its hot-path timeout/fallback contract). - **Config**: a JSON Schema. The admin renders a consistent Turkish settings form from it automatically. Most extensions ship zero UI code because of this. - **Secrets**: write-only credential fields (sealed with AES-GCM, never readable back, optionally locked to a sandbox prefix until live mode). - **Admin UI**: panels mounted into named [zones](/reference/admin-zones) of existing pages, actions (modals), and — rarely — own pages. - **Webhooks** it needs to receive (served by ONE platform-owned route), **jobs** (hourly/daily), **mail** template contributions (promo-free by attestation and lint), checkout **CSP** origins, **PII field selection**, and order-lifecycle **events** (field defined; dispatcher lands with the first e-invoice extension). - **`runtime`** — the declared dependency: see [Runtime model](/runtime-model). ## Install is per store Code physically present in Mozaik's workers does **not** exist for a store until that store installs the extension. Dispatch routes only through installed + enabled rows ([`extension.install`](/reference/commands/extension.install) → [`extension.enable`](/reference/commands/extension.enable)). The per-store row pins the extension's version and a snapshot of its manifest; upgrades are explicit audited commands ([`extension.upgrade`](/reference/commands/extension.upgrade)). ## What stays core (and why) Payment session state machine (money truth can't depend on extension correctness) · checkout orchestration (the composition point) · order + legal document generation (Turkish consumer-law artifacts) · the stock ledger (append-only, trigger-enforced) · the manual cargo path (a store with zero extensions must still fulfill) · the carrier VKN reference table · the hook runner and breaker · the mail transport and its promo-free enforcement · GİB mükellef lookup and e-Fatura/e-Arşiv routing (M7) · the İYS consent ledger (M10). ## The four permanent refusals From ADR 0020, unchanged: no extension-defined inbound routes or request middleware; no direct database access from extension code; no free `documentShell` injection; no per-store storefront forks.