Who can do what. And why, every time.
Ask
A person, an API key or an agent asks to do something.
Roles
The roles they hold, directly or through their groups.
Relationships
What they are to the thing they are asking about.
Conditions
Attributes, second factor and address — a missing attribute counts as unknown.
Decide
Allow or deny, with the path that granted it. A deny always wins.
01Models
Roles, attributes, relationships. One decision.
The model everyone knows, done carefully.
Built-in admin, member and viewer roles, and custom roles with exactly the permissions you set. Roles come from a person's groups, and every role says who holds it — directly or through a group.
- Built-in admin, member and viewer roles
- Custom roles, set in one call, renamed or deleted
- Each permission says which role or group grants it
PlansOn every plan
Rules about the request, not only the person.
Attribute-based policies with thirteen operators that fail closed. A condition can require a role or a relationship beside the attributes, and a policy can be tried before it is saved.
- Thirteen operators; a missing attribute counts as unknown
- Every version kept whole with its author, and restorable
- An unsaved policy can be tried first
PlansFrom Pro
Access that follows how things connect.
Zanzibar-style relationship tuples — this person edits that document, this team owns that project — checked recursively, with a limit on depth.
- Recursive checks, with a depth limit
- Relationships list their object types and objects, and name the people
- The grant path behind every answer
PlansFrom Pro
Your services ask. Qeet ID decides.
A standard AuthZEN decision point, so any of your services can ask Qeet ID whether an action is allowed — one evaluation at a time, or several in one call.
- A standard decision point for your services
- Several evaluations in one call
Where a sign-in may come from.
IP allow and deny rules decide every sign-in, the hosted sign-in page included — and a rule change that would lock out the admin making it is refused.
- Applied to every sign-in
- A change that would lock its admin out is refused
- One rule changed without resending the rest
PlansFrom Pro
02Explained
Every answer comes with its reason.
What you can see
The grant path
Ask with explain, and the answer traces the role or relationship that granted it.
The reason
Every authorization result carries a code that says why.
The decisions
The access decisions an organisation asks for are kept 30 days, and listed.
What it rules out
Deny wins
A refusing policy always wins over any allow.
Fail closed
A route without a policy is refused, and so is an error.
No self-promotion
Adding someone to a group checks the group's roles first.
Fewer privileges only
Admins act only on people with fewer privileges; only owners act on owners.
03Every caller
Machines are checked as closely as people.
By exact scope
A machine caller is authorised by its exact scope, on every route.
No wider than its maker
A key or an agent carries only scopes its creator holds.
Apps see their own people
An app can be limited to the people and groups assigned to it.
Hooks can say no
A sign-in hook can refuse a sign-in, and can be test-called before it goes live.
04On each plan
Roles on every plan. Policies from Pro.
Free
₹0/month
10,000 users
Starter
₹2,400/month
25,000 users
Pro
₹8,000/month
100,000 users
Enterprise
Custom
Custom scale
Roles and permissions: Free: 3 roles; Starter: Unlimited; Pro: Unlimited; Enterprise: Unlimited
Groups: not on Free; Starter: included; Pro: included; Enterprise: included
Attribute and relationship policies: not on Free; not on Starter; Pro: included; Enterprise: included
Address rules: not on Free; not on Starter; Pro: included; Enterprise: included
Sign-in hooks: not on Free; not on Starter; Pro: included; Enterprise: included