Tenant Management

Data tenancy ensures that data is isolated and accessible only to authorized credentials. Each tenant has a virtual view of data that is restricted to their own information, with no visibility into other tenants’ data.

Rustici Generator was built with data tenancy being a key component of the design. Many of Rustici Generator’s API endpoints require a tenant specification as part of the request, so it’s important to configure tenants before moving forward.

To configure tenants for your application, consider the following API endpoints as a starting point:

• Create new tenants: POST /api/v1/app_management/tenants
• Get a list of current tenants: GET /api/v1/app_management/tenants
• Delete tenant: DELETE /api/v1/app_management/tenants/{tenant_id}

Like all IDs used in the Generator API, the tenant IDs are case-sensitive. Generator will consider, for example, tenants with IDs of tenant and TENANT as separate, independent tenants.

NOTE: Rustici Generator and Rustici Engine each has a different approach towards case sensitivity for tenants. To account for these differences, Generator will convert Engine tenant names to lowercase. See Engine Integrations (specifically api_config) for more information.

Enabled and Disabled Tenants

Tenants have an enabled property that indicates whether or not resources within that tenant can be updated. This enabled property can be set during tenant creation or updated via the PUT /api/v1/app_management/tenants/{tenant_id} endpoint for existing tenants. When a tenant is disabled, the API will reject API requests that update resources within that tenant. All POST, PUT, and DELETE requests involving a disabled tenant will be rejected with a 409 Conflict response.