Organizations, applications and users
Three words the whole Console is built on — and the one of them you can do without
Before any screen, three words. Everything in the Console is one of them, and once you see how they fit, every screen is obvious.
And how they hang together — one organization, as many applications as you need, and the people with a seat in it:
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).
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, 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.
Where it is configured
Everything an application has is on its 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), Capabilities (this one), Webhooks (and this) and Layout & Aesthetics, how the widget looks. Every section carries its own tour and its own page here.
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.
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.
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, 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.