> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Systemplane admin API > Inspect and change a Lerian application's operational configuration at runtime — without a restart — through the shared Systemplane admin API. Systemplane is the shared runtime-configuration control plane that Lerian applications expose so you can inspect and change operational settings on a running service — without a restart. In regulated financial environments, taking a service down to apply a configuration change is both a compliance risk and an operational disruption. Systemplane removes that: you adjust the values a service safely supports while it keeps serving traffic. This is the same admin surface across every application that mounts it. Each product documents its own configurable keys, but the routes, request and response shapes, and authorization model described here are common to all of them. ## What Systemplane is *** Systemplane is not a standalone service. Each application mounts the same route set onto its own HTTP host and port under an application-specific path prefix — there is no dedicated Systemplane host or port, and no dedicated admin port. The canonical prefix documented here is `/system`, but it varies per application (see the applicability table below). Because the routes are registered programmatically rather than emitted by a code generator, they do not appear in each product's generated API reference. This reference documents the surface by hand so you can operate it consistently across products. The whole surface is off by default. An application serves it only when the `SYSTEMPLANE_ENABLED` setting is turned on; otherwise the application runs in environment-variable-only mode and these routes are not mounted. ## Namespaces *** Configuration is organized into **namespaces**, each holding flat, string-keyed entries. Rails and plugins use three canonical namespaces: | Namespace | What it holds | | ---------------------- | ----------------------------------------------------------------------------------- | | `runtime_config` | Operational knobs such as rate limits, worker intervals, and connection-pool sizes. | | `tenant_policy` | Tenant-scoped policy objects (for example, per-tenant routing tables). | | `operational_registry` | Operational lookup data the service reads at runtime. | Some applications register a single application-named namespace instead of these three. Matcher, for example, keeps all of its keys under a single `matcher` namespace. Each entry's value is untyped at the transport layer: every registered key accepts its own JSON scalar, object, or array, validated by that key's server-side validator. Not every setting is runtime-changeable — bootstrap-only settings are read once at startup, are not registered in Systemplane, and still require a restart to change. ## Endpoints *** All paths are relative to the application's prefix (default `/system`). | Method | Path | What it does | | -------- | ------------------------------------- | ------------------------------------------------------------------------------------------------ | | `GET` | `/system/{namespace}` | [List entries](/en/reference/systemplane/list-entries) in a namespace | | `GET` | `/system/{namespace}/{key}` | [Get one entry](/en/reference/systemplane/get-entry) | | `PUT` | `/system/{namespace}/{key}` | [Write one entry](/en/reference/systemplane/put-entry) — body `{"value": }`, returns `204` | | `DELETE` | `/system/{namespace}/{key}` | [Delete one entry](/en/reference/systemplane/delete-entry) — returns `204` | | `GET` | `/system/-/catalog` | [List the key catalog](/en/reference/systemplane/catalog-list) (opt-in) | | `GET` | `/system/-/catalog/{namespace}/{key}` | [Get one key's write contract](/en/reference/systemplane/catalog-detail) (opt-in) | `/system/-/catalog` is a reserved metadata path served before the namespace routes — `-` is not a real namespace and cannot be used as one. Errors use a flat `{"code": , "title": "", "message": ""}` envelope. ## Authentication and permissions *** Authorization is **deny-all by default**. An application serves the surface only once it is configured with an authorizer; without one, every request is denied. When authentication is enabled, the application enforces per-namespace role-based access control on top of a valid, platform-scoped (non-tenant) identity. Reads require the namespace's read permission and writes require the matching write permission: | Namespace | Read permission | Write permission | | ---------------------- | ---------------------------------- | ----------------------------------- | | `runtime_config` | `system_runtime_config:read` | `system_runtime_config:write` | | `tenant_policy` | `system_tenant_policy:read` | `system_tenant_policy:write` | | `operational_registry` | `system_operational_registry:read` | `system_operational_registry:write` | The read action covers `GET`; the write action covers `PUT` and `DELETE`. The catalog discovery endpoints require read permission for at least one namespace. The exact permission strings can vary per application. Matcher, which uses a single namespace, protects its whole surface with the `system-runtime-config:admin` permission (resource `system-runtime-config`, action `admin`) rather than the per-namespace strings above. Check the product's own documentation for its authorization model. Tokens are bearer JWTs issued by the platform's [Access Manager](/en/platform/access-manager/access-manager); machine callers obtain one through the client-credentials flow. ## Discovering keys with the catalog *** When an application opts into the catalog surface, `GET /system/-/catalog` lists every key it registers, and `GET /system/-/catalog/{namespace}/{key}` returns one key's full write contract — its kind, tenant scope, runtime class, redaction policy, JSON schema, validation rules, valid examples, default value, and the matching `PUT` path. Use the catalog to learn what a service exposes before you change anything: the catalog describes the write contract, while the current configured value is read from `GET /system/{namespace}/{key}`. ## Which products expose Systemplane *** Systemplane is opt-in per product. The table below lists the products that mount it, the path prefix each uses, its default HTTP port, and whether it also serves the catalog discovery surface. The prefix and port are defaults — a deployment can override them. | Product | Path prefix | Default port | Catalog? | | ------------------------------------------------------------------------------------------------------------- | --------------------- | ------------------ | -------- | | [Matcher](/en/matcher/configuration/matcher-systemplane) | `/system` | `:4018` | Yes | | [Lender](/en/lender/what-is-lender) | `/api/v1/systemplane` | `:8080` | No | | [TED (via JD)](/en/rails/ted/ted-overview) | `/system` | `:4027` | Yes | | [Pix Direto (via JD)](/en/rails/pix/main-domains-overview) | `/system` | `:8080` | No | | Pix multi-provider switch | `/lerian/v1/system` | Deployment-defined | No | | CCS integration | `/system` | `:4030` | No | | SPB file exchange (BC-Correios) | `/system` | `:9090` | Yes | | [Lerian STA](/en/rails/native/sta/what-is-lerian-sta) | `/system` | `:4028` | No | | [Lerian SISBAJUD](/en/rails/native/sisbajud/what-is-lerian-sisbajud) | `/system` | `:4029` | No | | [Lerian SLC](/en/rails/native/slc/what-is-lerian-slc) | `/system` | `:4111` | No | | [Lerian Consignado — Dataprev](/en/rails/native/consignado/what-is-lerian-consignado) | `/system` | `:8080` | No | | [Lerian SPB](/en/rails/native/spb/what-is-lerian-spb) / [Lerian SPI](/en/rails/native/spi/what-is-lerian-spi) | `/v1/system` | Per service | No | Products not listed here do not mount Systemplane — they are configured through environment variables only.