> This page is for The Console.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://infonite.dev/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://infonite.dev/_mcp/server.

# Organizations, applications and users

Before any screen, three words. Everything in the Console is one of them, and once you see how they fit, every screen is obvious.

#### Organization

**The container. It is you** — your company, as a customer of INFONITE. Everything you have with us hangs from it: the applications, the people with a seat, the contract. There is one per company, and it is created by our team, never from a form.

#### Application

**The thing that runs — and a closed world.** An application is what gets authorized to run engines and flows. It belongs to one organization, holds its own keys, and shares nothing with any other application on the platform.

#### User

**A person with a seat.** Users are given a seat in an organization so they can manage its applications from the Console. Take every user away and the organization and its applications are still there, working.

And how they hang together — one organization, as many applications as you need, and the people with a seat in it:

```mermaid
flowchart LR
  ORG["Organization<br /><i>your company</i>"]:::io
  APP1["Application<br /><i>Loans</i>"]
  APP2["Application<br /><i>Customer verification</i>"]
  APPN["Application<br /><i>… N</i>"]
  U1["User<br /><i>Jane, manager</i>"]
  U2["User<br /><i>Luis, developer</i>"]
  ORG --> APP1
  ORG --> APP2
  ORG --> APPN
  U1 -. "seat" .-> ORG
  U2 -. "seat" .-> ORG
  classDef io stroke-width:1.5px
```

---

## The organization

Think of it as the building. Your contract, your applications, your team's seats: all inside. One organization per company, and if you work with more than one company, the Console lets you switch between them from the bottom of the side menu — every application you see belongs to the organization you are standing in.

You do not create organizations. Ours is a by-invitation platform: your organization is created by our team, and the first seat in it is ours to hand you (see [getting access](/console#getting-access)).

---

## The applications

If the organization is the building, an application is a **room with its own key and its own walls**. It is the unit of everything technical:

* **It is what gets authorized.** Engines and flows are enabled per application, so one of your applications can run a bank engine that another cannot.
* **It is what identifies itself.** Every call to our APIs carries an application secret, and every execution and every session is recorded under the application that started it.
* **It is what your customers see.** The public name, the logo and the colours of the widget are the application's.
* **It is what receives.** Webhooks, redirect URLs, encryption keys: all configured on the application.
* **It is sealed.** Everything recorded under an application stays inside it: its customers, its executions and sessions, the [credentials it tokenized](/guides/credential-tokenization), its keys. Nothing is visible from — or usable by — any other application on the platform, not even one in the same organization. If *tenant* is a word you use, that is what an application is.

Why more than one? Because one company rarely does one thing, and the things it does should not see each other. A loans product and a customer-verification service are different rooms: different keys, different webhooks, different customers — and a secret revoked in one, or a token stored in one, means nothing in the other. Create as many as you need; each one starts from zero.

#### Every application is born in the sandbox

New applications start in the **sandbox** environment: the same API, the same screens, rehearsal data — safe for integrating and testing. Nothing you do there touches a real institution or a real person.

#### Production is a request, not a switch

You raise it from the application's own **General** settings and we answer it — a conversation about what you will run and for whom, which is also when the products you need get granted. [How to ask, and what it freezes](/console/your-first-app#asking-for-production).

#### Locked means read-only, never gone

An application can be locked — by request, or while something is looked into. Locked, it stops running and its settings become read-only in the Console; its data and its configuration stay exactly where they were.

### Where it is configured

Everything an application has is on its [**App Settings**](/console/app-settings) screen — the one the Console opens on — in five sections: **General** (names, website, the redirect URLs and the move to production), **Security & Keys** ([this guide](/console/security-and-keys)), **Capabilities** ([this one](/console/capabilities)), **Webhooks** ([and this](/console/webhooks)) and **Layout & Aesthetics**, how the widget looks. Every section carries its own tour and its own page here.

#### [Your first application](/console/your-first-app)

Creating one, what it can already do in sandbox, and how to ask us for production.

#### [App settings](/console/app-settings)

The names, the redirect URLs and the danger zone, section by section.

---

## The users — the part you can do without

A user is a person with a **seat** in an organization. The seat is what lets them open the Console for that organization; the **role** on the seat is what decides what they can do there.

| Role                     | What the seat can do                                                                                                                                   |
| :----------------------- | :----------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Organization manager** | Everything: the applications and their settings, the keys, the webhooks, the dashboards. This is *your* administrator — the person who runs your side. |
| **Developer**            | A seat that exists to be granted; it opens the organization and its permissions are being defined.                                                     |

Two things about users that surprise people, and that are the point:

#### A user can belong to several organizations

One account, one password, one profile — and a seat in each organization that gave them one. An integrator who works for two of your subsidiaries switches between them; they do not need two accounts.

#### Users are the only piece that is optional

Remove every seat from an organization and **nothing else changes**: the applications keep running, the webhooks keep delivering, the keys keep working. Users administer; they do not hold anything up.

Which is why you can choose not to self-serve at all. An organization with no users is perfectly valid — its applications are then administered by INFONITE's own team, on your instructions. If that is how you would rather work, write to `support@infonite.tech` and we will be glad to manage your service.

> **Warning**
>
> **A seat is not a key.** Signing in as a user lets you *see* and *configure* — it never authenticates an API call. Your backend speaks to us with an [application secret](/console/security-and-keys), and that secret keeps working whether the person who minted it still has a seat or not.

---

## In one breath

Your **organization** is you. Your **applications** are what runs, and what holds the keys. Your **users** are whoever you want managing them — or nobody, and then we do.

#### [Next: Security & keys](/console/security-and-keys)

The secret your backend signs in with, and the key pair for encrypting what you send.

#### [Your account](/console/your-account)

What is yours as a person: profile, language, sign-in and the tours.