Tenancy and identity
Each Customer of an API holds one Tenant; its people, keys and agents act inside it, and every call records who acted and for whom.
Each Customer of an API holds one Tenant: the partition of records, keys and Limits that belongs to it. Every call names who made it and whom it was for.
One Tenant per Customer
When Harbor Residential became a Leaseline Customer, Tenant.provision made its Tenant with keys, defaults and an admin invitation in one Action. Its leases live there, and no query from another Customer reaches them, whatever its filter.
Limits apply per Tenant, so one Customer's traffic never spends another's capacity. Tenancy is the capability underneath.
Who acts inside a Tenant
| Who | How they get in | What they hold |
|---|---|---|
| A Person at the Customer | Tenant.invite, or the Customer's own sign-in | A session in the Portal and the App |
| The Customer's people, in bulk | Single sign-on and directory sync, set up through Tenant.requestSetup | Membership that follows the Customer's directory |
| The Customer's code | A key made in the Portal | A test or live key that reaches this Tenant only |
| The Customer's Agent | A key, or a Mandate to buy on the Customer's behalf | The same reach as the key or Mandate it carries |
Customer access runs members, invitations, sign-in and keys. Your customers' API keys covers making, scoping, rolling and revoking keys.
By and for
Every Action records its caller as by and the Party it serves as for. When Harbor Residential's sync renews a lease, the Action names the sync's key as by and Harbor Residential as for.
An Agent acting under a Mandate records the Agent as by, the Customer as for, and the Mandate it acted under. Receipts, Limits and support all reach the right party from those two fields.
The builder side
Leaseline's own Workers never hold a Customer's key. Its Success Manager agent holds a session key for its Role on the builder plane, which reaches every Tenant that Role grants. Revoking that key stops that agent and nothing else.