> ## Documentation Index > Fetch the complete documentation index at: https://docs.sqwish.ai/llms.txt > Use this file to discover all available pages before exploring further. # Organisations > Work with other people in a shared organisation, each with a role. An organisation is shared by several people, each with a role. It has its own keys, data, models and credit, and pays for its own work. Your personal organisation, **Personal** in the console, is yours alone. Switch between them in the organisation menu, under the brand. Each browser tab keeps its own choice. You can't move data, keys or credit between organisations. ## Make an organisation Choose **New organisation** in the organisation menu and name it. You become its owner. Your account must be off the waitlist, and you must have signed in with a code sent to your address. A new organisation has no credit, and its tier comes from its own purchases. Buy credit in **Billing** before its first decision. ## Invite people 1. In **Organisation settings**, on the **Members** tab, choose **Invite member** and pick a role. 2. We email the invitation. It stays open for 14 days. 3. They sign in with that address, which creates an account if they have none, and accept it in **Invitations**. Only an owner can invite, once their own account is off the waitlist. The owner and the person invited must both have signed in with a code sent to their address. Someone on the waitlist can still join and work in the organisation. Joining moves them to the waitlist's priority line. Inviting an address again replaces its open invitation. Owners can withdraw open invitations, and each can send a limited number a day. ## Roles | Role | Can | Its keys can call | | - | - | - | | Owner | Everything, including members and money | Every route the key's access allows | | Developer | Keys, data, models and decisions, not money | All but `/v1/account/payments`, `/v1/account/wallet` and `/v1/account/automatic-topup` | | Billing | Payments, top-ups and usage | Those three, `GET /v1/account`, `/v1/account/usage` and `GET /v1/models` | Only owners manage members and invitations, and rename or delete the organisation. Owners and billing members choose where the bills go and which emails come. The console shows each role only the pages it can use. An organisation always has an owner. The last owner can't leave, change role or delete their account until someone else is an owner. ## Keys in an organisation A key works only in the organisation it was made in, with the role it was made with. That role is at most its maker's: owners make keys of any role, developers make developer keys, and billing members make none. Owners can revoke any key, developers only their own. `GET /v1/account/keys` shows each key's `role` and `made_by`, the member who made it. In your personal organisation, every key's role is `owner`. A call needs both the key's [access](https://docs.sqwish.ai/guides/accounts-and-usage.md#access-and-keys) and its role to allow it. A route the role doesn't allow, such as the wallet for a developer key, gets `403 role_forbidden`. A key stops working while its maker is suspended (`403 account_blocked`). In `GET /v1/account`, a shared organisation's key sees the organisation, not its maker. `user.email` is the billing email, or `null` for a developer key, and `referrals` is `null`. ## When someone leaves or changes role | Change | The keys they made there | | - | - | | They leave | Stop working | | An owner removes them | Stop working, unless the owner ticks **Keep the keys they made** | | They become a developer or billing member | Owner keys take the new role. Keys made with the other role stop working | | They become an owner | No change | | They delete their account | Stop working, in every organisation | The console lists the keys that will stop before you confirm. Someone who rejoins keeps no key above their new role. A kept key works on after its maker deletes their account. If an organisation needs your keys, ask an owner to remove you and keep them before you delete your account. Someone who goes, or loses billing access, also takes their saved card off the automatic top-up. It stays off until someone adds another card in **Billing**. The other owners and billing members get an email when: * the bills still go to that person * the person's keys stopped as they left or deleted their account * the top-up lost their card ## Where the bills go Bills go to the organisation's billing email, at first its maker's address. Owners and billing members can change it in **Organisation settings** to the address of any owner or billing member who has signed in with a code. The billing email gets invoices, receipts, credit reminders and the organisation's other account emails. It is a contact, not a role: | When its person | The bills | | - | - | | Goes, or loses billing access | Still go to them until someone changes it. The settings say so, and the other owners and billing members get an email | | Changes their address in the console | Follow them, while they are a member | | Deletes their account | Go to the longest-standing owner | Owners and billing members switch **Credit reminders** and **Model updates** for the organisation in **Organisation settings**. An email's unsubscribe link turns its kind off for the organisation. ## Delete an organisation An owner deletes it in **Organisation settings**, typing its name to confirm. Its keys stop at once, its top-up switches off and its members lose access. Its credit isn't refunded. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.