> ## Documentation Index
> Fetch the complete documentation index at: https://rain-sandbox-trial.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Customers and Identity
> How tenants, companies, users, and authorized users relate, and how to tie Rain records to the customers in your own system.
Every Rain product acts on a customer record. Get the identity model right once
and the rest of the platform follows, because the same records carry across
cards, accounts, and money movement.
## The four levels
Rain's identity model has four levels. Which ones you use depends on your
program type:
| Level | What it is |
| :------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Tenant** | Your program. Your API keys are scoped to it, and everything you create belongs to it. |
| **Subtenant** | A program running underneath yours, with its own customers. Subtenants complete their own verification before your program goes live. See [Managing subtenants](/docs/managing-subtenants). |
| **Company** | A business customer. Corporate programs verify the company through KYB, along with its users and ultimate beneficial owners. |
| **User** | An individual. Consumer programs verify the person through KYC. In a corporate program, users are the people who belong to a company. |
Your program type decides whether you start from a company or a user. Consumer
programs create users directly. Corporate programs create a company first, and
the corporate application also creates that company's first user. See
[Flow of funds](/docs/first-steps) for what else the choice affects.
### Authorized users
An authorized user is an additional person you attach to an existing customer,
for example a second cardholder on a company account. Authorized users are
enabled per program; contact Rain if your program needs them.
## One record, several products
A user or company is not a cards object. It's a platform object that every
product references.
The same `userId` or `companyId` you use to issue a card is the identifier you
pass when you create a payment route to move money, and the ledger opens one
account per user or company regardless of which products they use. That's what
makes adding a second product cheap: no second customer directory, no
reconciliation between two views of the same person.
Sharing a record is not sharing an approval. Cards KYC or KYB and payments
verification are separate gates, and clearing one does not clear the other.
Check the relevant status before you act. See
[Payments compliance](/docs/payments-compliance).
## Mapping Rain records to your own
Rain identifies customers by UUID, but you probably already have your own
identifier for the same person. Set `externalId` to carry it, and you can look
customers up by your identifier instead of storing a mapping table.
`externalId` is a string of up to 255 characters that must be unique within your
tenant. You can set it when you create a customer or an application, and change
it later:
| Where | Endpoint |
| :---------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Creating a user | [Create a user in a company](/reference/users/create-a-user-in-a-company) |
| Creating an application | [Create a consumer application](/reference/applications/create-a-consumer-application-for-a-user), [Create a corporate application](/reference/applications/create-a-corporate-application-for-a-company) |
| Updating | [Update a user](/reference/users/update-a-user), [Update a company](/reference/companies/update-a-company) |
Once it's set, four lookups accept your identifier in place of Rain's:
| Lookup | Endpoint |
| :----------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| A user | [Get a user by external id](/reference/users/get-a-user-by-external-id) |
| A company | [Get a company by external id](/reference/companies/get-a-company-by-external-id) |
| A user's application status | [Get the status of a user's consumer application by external id](/reference/applications/get-the-status-of-a-users-consumer-application-by-external-id) |
| A company's application status | [Get the status of a company's corporate application by external id](/reference/applications/get-the-status-of-a-companys-corporate-application-by-external-id) |
`externalId` must be unique within your tenant. Reusing a value that already
belongs to another customer fails, so derive it from a stable primary key in
your own system rather than from something a customer can change.
## What's next
Where customer records sit relative to compliance, products, and the ledger.
Consumer or corporate, Rain-managed or partner-managed.
What each verification pipeline unlocks for a customer record.
Submit an application and take a customer through verification.