π’ Multi-Tenant Support
EazyRent supports a hierarchical multi-tenant model, allowing organizations to manage multiple sub-entities (e.g., offices, branches, subsidiaries) with isolated resources and permissions.
π Organization Contextβ
By default, all API operations are executed in the context of the organization associated with the authenticated user.
However, in some cases, users may need to access or act on behalf of another organization. To support this, you can use the X-Eaz-Account-Id
header.
π‘οΈ Permissions Matterβ
Even when the header is provided, the system will enforce permission checks:
- The requesting user must explicitly have access to the target organization.
𧬠Organizational Hierarchy Exampleβ
Letβs say your organization is structured as follows:
Your Organization (ID: 000123)
βββ Office 1 (ID: 000124)
βββ Office 2 (ID: 000125)
βββ Office 3 (ID: 000126)
π Access Rulesβ
-
A user registered in the parent organization (
000123
) can access all child accounts (000124
,000125
,000126
) if they have the proper permissions. -
In the web console, these accounts are accessible through an account selector when logged in to the parent organization.
-
A user registered in a child account (e.g., 000124) cannot access the parent organization or its sibling accounts. Access is strictly scoped.
π‘ API Behavior with X-Eaz-Account-Id
β
This behavior also applies to the API via the X-Eaz-Account-Id
header.
π Acting on Behalf of a Child Accountβ
When a user or service account from the parent organization (000123
) needs to interact with a child account (e.g., 000124
), they can use the X-Eaz-Account-Id
header to act within the context
of that child account.
π Exampleβ
GET /v2/products HTTP/1.1
Host: api.eazyrent.com
Authorization: Bearer <access_token_of_org_000123>
X-Eaz-Account-Id: 000124
In this request, although the token belongs to the parent organization (000123
), the request is scoped to Office 1 (000124
). This allows centralized service accounts to access sub-account data without compromising isolation.