The Platform distinguishes two key types by their **owner**. Both share the format, creation with a confirmation code, and how they're used — what changes is who can create each one and with what permissions it acts. | | Personal key | Company key | | --- | --- | --- | | **Who creates it** | Any role, for themselves | Admin role only | | **Real owner** | Your own user account | A tenant service account (not a person; has no password and can't log in with it) | | **Permissions it acts with** | Your **role's**, as it was at the moment the key was created | An **administrator's**, always — regardless of who created it | | **Where it's managed** | Profile → My API keys | Settings → API keys | | **Who can revoke it** | You, or any admin on the tenant | Any admin on the tenant | > **Note — Permissions are sealed when the key is created** > > A personal key inherits your role's set of permissions **at the exact moment you create it** — it doesn't > update itself afterward. If your role changes later on (for example, you go from editor to admin), keys > you already had created keep the old permissions: you'd have to revoke it and create a new one to reflect > your current role. > **Warning — A company key acts as an administrator, always** > > It doesn't matter what role the person who created it has (only an admin can create them, but that's a > requirement for CREATING it, not something that limits what the key can do): a company key always acts > with an administrator's full set of permissions. Any integration using it can do the same as an account > administrator — treat it with the same care as an admin's password.