Concepts

Tenants

A tenant is one platform on Nimles: a shop, a marketplace, a company’s site, your app. Everything else (users, content, products, orders) belongs to exactly one tenant, and every API URL names it:

https://api.nimles.com/{service}/api/tenant/{tenantId}/{Resource}

A tenant has its own Identity: its own users, its own clients and its own sign-in at https://auth.nimles.com/tenant/{tenantId}/. In the developer beta you create tenants in the portal and become their Owner.

Organizations

An organization is a company or team inside a tenant: a shop on a marketplace, a customer of your SaaS. It has members, and can have its own custom domains and single sign-on. Organizations are optional; a tenant for a single site may never use them.

Resource groups

Content lives in resource groups, the folders that access is granted on. A resource group belongs to the tenant directly, or to an organization, and can have child groups (parentId).

• A new tenant gets one resource group, Default.
• A create names its resource group in the body (resourceGroupId), and the service checks the caller’s access there. The resource group (and the organization) are set at create and cannot be changed by an update.
• Many list endpoints take resourceGroupId to filter (see the resources reference).

Find your groups with GET /identity/api/tenant/{tenantId}/ResourceGroups.

Users and clients

Two kinds of principals call the API:

• Users sign in interactively at auth.nimles.com/tenant/{tenantId}/ (authorization code with PKCE). A user’s app calls the API with the user’s token, and the user’s roles decide what it may do.
• Clients are applications. An API client is an OAuth 2.0 client in your tenant that signs in with the client credentials grant: you exchange its client id and secret for a short-lived access token (see Authentication). It has roles like a user.

Principals can hold roles in tenants other than their home tenant. Your own account lives in the Nimles platform tenant (where you signed up), and is Owner of the tenants you created; that is how the portal works on them.

Roles and actions

Access works like Azure RBAC. A role assignment gives a principal (a user, a group or a client) a role at a scope:

Scope	Covers
Tenant	Everything in the tenant
Organization	The organization and every resource group in it
Resource group	That resource group and its descendants, not the organization above it

A role is a set of allowed actions and denied not-actions. Actions are named {Provider}/{resource}/{operation} with * wildcards, for example Nimles.Cms/pages/read, Nimles.Pim/products/write or Nimles.Ecommerce/orders/delete. Not-actions are checked first: a denied action stays denied whatever else allows it.

The built-in roles:

Role	Allows	Denies
Owner	*: everything	–
Contributor	*	Writes and deletes in Identity and AccessControl: users, groups, clients, resource groups, organizations, roles and role assignments
Reader	*/read: every read	–
User Access Administrator	Role assignments (read, write, delete) and reading role definitions	–

Tenants can define their own roles with RoleDefinitions, and assign them with RoleAssignments.

Every endpoint checks an action. A request without a role that allows it at the right scope answers 403. API clients created in the portal get their role at tenant scope, so they act on the whole tenant.

Accessibility

Every item has an accessibility member: Inherit (the default), System, Application, Private, Shared, SharedExplicit, Public or PublicExplicit. It is set at create and cannot be changed afterwards.

Accessibility does not open the API: every API call needs a token and a role, whatever an item’s accessibility. Today it is used by the content host: a Media file that is Public or PublicExplicit is served with a public cache header. Public sites built on Nimles read their content through their own backend with a token (see API conventions).