> ## Documentation Index > Fetch the complete documentation index at: https://alguna.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Organizations and Environments > How Alguna is scoped: your organization, its sandbox and production environments, the entities you sell from, and how to model your own tenants as customers. Everything in Alguna belongs to an **organization** — your company's account. Customers, products, subscriptions, invoices, API keys and settings are all scoped to it, and nothing is shared with another organization. Inside your organization sit two independent environments, one or more selling entities, your team, and your customers. This page explains that structure, and then how to map your own product's tenants onto it. *** ## The organization The organization is the boundary. Every record carries its organization, every API key is issued against one, and every query is answered within it. If your company has one Alguna account, that is your organization. Inside it: | | What it is | Where | | ------------------- | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | | **Environments** | Sandbox and production — separate data, separate keys | [Testing and sandbox](/docs/getting-started/testing) | | **Legal entities** | The registered businesses you invoice from, each with its own tax registration and FX rates | **Settings → Legal entities** | | **Merchants** | Display identity for businesses you sell on behalf of; your legal entity stays seller of record | [Legal entities and merchants](/docs/customers/customer-management#legal-entities-and-merchants) | | **Users and roles** | Your team's access, by role | **Settings → Admin → Users management** | | **Customers** | The accounts you bill | [Manage customers](/docs/customers/customer-management) | Business details, branding, tax configuration, invoicing rules and automations are all organization-level: set once, applied to everything underneath. *** ## Environments Sandbox and production are two complete, independent copies of that structure. A key issued in one is rejected by the other, records do not exist across both, and there is no copy or promote step between them. | | Production | Sandbox | | --------- | -------------------------------------- | ------------------------------------------------------ | | Dashboard | [app.alguna.io](https://app.alguna.io) | [app.sandbox.alguna.io](https://app.sandbox.alguna.io) | | API | `https://api.alguna.io` | `https://api.sandbox.alguna.io` | | Money | Real | Your processor's test mode | Switch between them with the environment switcher in the dashboard, or by changing the base URL and key in your integration. Configuration you build in sandbox is not carried across — see [Testing and sandbox](/docs/getting-started/testing) for how to work with both. *** ## Selling from more than one entity If you invoice from several registered businesses — one per country, say — model each as a **legal entity** and assign each customer to the right one. The legal entity is the *From* party on the invoice, carries the tax registration, and owns the receivable; tax treatment and [revenue schedules](/docs/revenue/recognition) follow that assignment. A **merchant** is a different thing that is easy to confuse with it: display identity only, for invoices you issue on behalf of another business. Your legal entity remains seller of record. Both are covered in [Legal entities and merchants](/docs/customers/customer-management#legal-entities-and-merchants). *** ## Modelling your own tenants If your product is multi-tenant, the question is usually how *your* tenants, workspaces or accounts map onto Alguna. The mapping is: **Your billable tenant is an Alguna [customer](/docs/customers/customer-management).** Whatever unit signs up, gets an invoice and can churn — a workspace, an org, a team — is one customer record. From there: * **Keep your own IDs, don't store Alguna's.** Put your tenant identifier in the customer's `aliases`. Every endpoint that takes a customer `{id}` also accepts an alias, so `GET /customers/tenant_abc123` works with no ID mapping table on your side. [`GET /customers/lookup?alias=…`](/docs/api-reference/v2/2026-04-01/customers/look-up-a-customer-id-by-alias) resolves one to the Alguna ID when you do need it. * **Attribute usage by the same identifier.** [Usage events](/docs/billable-metrics/send-usage) carry `account`, which accepts a customer ID or any of its aliases — so your meter emits the tenant ID it already has. * **Nest tenants one level with [customer families](/docs/customers/customer-families).** A parent customer with child customers gives you a group that can be invoiced together through [roll-up billing](/docs/invoices/rollup-billing) while usage and revenue stay attributed to the child that incurred them. The relationship is set in the dashboard, not the API. * **Gate features per tenant with [entitlements](/docs/entitlements/overview)**, rather than reading subscription state and inferring access in your own code. Two things not to do: don't create an Alguna organization per tenant — organizations are for *your* company, not your customers, and per-tenant organizations break reporting, catalog reuse and API access. And don't reuse one customer record for several of your tenants; a customer is the unit of invoicing, so merged tenants cannot be billed or churned separately later. *** ## Next steps The object graph from catalog to revenue. Working across the two environments. Customer records, aliases and legal entities. Turn a subscription into per-tenant feature access.