> ## 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 control plane for runtime configuration that Lerian applications share. They expose it 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. With Systemplane, 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. Systemplane has no host or port of its own, and no dedicated admin port. The canonical prefix documented here is `/system`, but it varies per application (see the applicability table below). Applications register the routes programmatically, and no code generator emits them. They therefore 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 you turn on the `SYSTEMPLANE_ENABLED` setting. Otherwise the application runs in environment-variable-only mode and does not mount these routes. ## Namespaces *** Configuration lives in **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 has no type at the transport layer. Every registered key accepts its own JSON scalar, object, or array, and its own server-side validator checks the value. Not every setting is runtime-changeable. The application reads bootstrap-only settings once at startup. These settings do not appear 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/platform/systemplane/list-entries) in a namespace | | `GET` | `/system/{namespace}/{key}` | [Get one entry](/en/reference/platform/systemplane/get-entry) | | `PUT` | `/system/{namespace}/{key}` | [Write one entry](/en/reference/platform/systemplane/put-entry) — body `{"value": }`, returns `204` | | `DELETE` | `/system/{namespace}/{key}` | [Delete one entry](/en/reference/platform/systemplane/delete-entry) — returns `204` | | `GET` | `/system/-/catalog` | [List the key catalog](/en/reference/platform/systemplane/catalog-list) (opt-in) | | `GET` | `/system/-/catalog/{namespace}/{key}` | [Get one key's write contract](/en/reference/platform/systemplane/catalog-detail) (opt-in) | `/system/-/catalog` names a reserved metadata path. The application serves it before the namespace routes. The `-` segment is not a real namespace, and you cannot use it 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 after you configure an authorizer. Without an authorizer, the application denies every request. When you enable authentication, 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 from the platform's [Access Manager](/en/platform/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. The detail route `GET /system/-/catalog/{namespace}/{key}` returns one key's full write contract. The contract covers 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. To read the current configured value, call `GET /system/{namespace}/{key}`. ## Which products expose Systemplane *** Systemplane is opt-in per product. The table below lists the products that mount it. For each product it gives the path prefix, the default HTTP port, and whether the product 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/products/matcher/configuration/matcher-systemplane) | `/system` | `:4018` | Yes | | [Lender](/en/products/lender/what-is-lender) | `/api/v1/systemplane` | `:8080` | No | | [TED (via JD)](/en/interfaces/ted/ted-overview) | `/system` | `:4027` | Yes | | [Pix Direto (via JD)](/en/interfaces/pix/main-domains-overview) | `/system` | `:8080` | No | | [Pix Lerian](/en/interfaces/pix-lerian/pix-lerian-environment-variables) | Provided during onboarding | Per component | No | | CCS integration | `/system` | `:4030` | No | | SPB file exchange (BC-Correios) | `/system` | `:9090` | Yes | | [Lerian STA](/en/rails/sta/what-is-lerian-sta) | `/system` | `:4028` | No | | [Lerian SISBAJUD](/en/rails/sisbajud/what-is-lerian-sisbajud) | `/system` | `:4029` | No | | [Lerian SLC](/en/rails/slc/what-is-lerian-slc) | `/system` | `:4111` | No | | [Lerian Consignado — Dataprev](/en/rails/consignado/what-is-lerian-consignado) | `/system` | `:8080` | No | | [Lerian SPB](/en/rails/spb/what-is-lerian-spb) / [Lerian SPI](/en/rails/spi/what-is-lerian-spi) | `/v1/system` | Per service | No | Products not listed here do not mount Systemplane. You configure them through environment variables only.