What is the DEFAULT tenant ID for in a Tazama deployment?

Tazama's multi-tenancy design uses a single data and processing path for both multi-tenant and single-tenant systems, rather than maintaining separate paths. The tenant is determined from the JWT issued by the authentication service (Keycloak), so even in a single-tenant deployment, users are set up with a TENANT_ID attribute.

The DEFAULT tenant ID covers the case where Tazama is deployed without Keycloak: with no JWT from which to derive the user's tenant ID, any unauthenticated access to a Tazama API is assigned the tenant ID DEFAULT inside the API itself.

An out-of-the-box deployment from tazama-stack is usually single-tenant (a multi-tenant option exists but is used only for testing). That single tenant is set up in Keycloak with a TENANT_ID of DEFAULT so that you can switch between authenticated and non-authenticated testing over the same data.

In short: you do not need to change it for a single-tenant deployment - DEFAULT is the deliberate convention that keeps authenticated and unauthenticated access pointing at the same tenant's data, but if you want to change it to something else (e.g. matching your organization name), you can change the TENANT_ID attribute for all users and user groups in KeyCloak.