A catalog, not a switch
Users, products, pricing, availability, taxes, bookings, tickets, reports, leads, support and API keys each have their own dedicated permission, so a role gets built from exactly the pieces it needs.
Roles & Permissions
Access, cut exactly to size.
Every organization builds its own roles from a catalog of granular permissions, and can restrict a single agent to specific products or collections, dynamically, without ever handing over more than intended.
- 28 permissions From managing users to redeeming tickets, each one grantable completely on its own
- Dynamic scoping Add a product to an already-assigned collection, and a restricted agent has it immediately, no re-configuration
- Rechecked live Revoking a permission mid-session takes effect immediately, not on the next login
Four pieces of access control.
Each one narrows what a person can do or see, without narrowing what the platform itself can do.
Scoped by product or collection
Beyond the permission itself, an individual agent can be limited to specific products or collections, for a regional team, a single venue, or one brand within a larger operation.
Scoping that stays current on its own
Restricting someone to a collection, not an individual product list, means a product added to that collection later is visible to them immediately, with nobody going back to update the assignment.
Sales and support, deliberately separate
leads.view and support.view are two different permissions, so a person can manage commercial opportunities without ever seeing technical support tickets, or the reverse.
How it resolves
How access actually gets decided
Five steps, from a role being defined to a single click being allowed or blocked.
- 1
A role gets built from the catalog
An organization creates its own roles and assigns exactly the permissions each one needs, from a fixed, versioned list, never a free-text field.
- 2
A user can be scoped beneath their role
Beyond the role's permissions, a user can additionally be restricted to specific products or collections, narrowing what they can see and act on within whatever their role already allows.
- 3
Every list respects both layers
Listings, the dashboard and operational queries all filter by both the permission and the product scope together, never just one of the two.
- 4
A scoping change gets re-validated, not trusted blindly
Updating someone's product access re-checks every id against what the organization, and the acting admin's own access, actually allow, closing the door on a tampered request trying to grant more than intended.
- 5
A revoked permission acts immediately
Sensitive actions re-check permissions in real time within the same active session, so pulling access from someone mid-session takes effect right away, not only the next time they log in.
The API, as it is
What restricting a user actually looks like
A user, a list of product ids, a list of collection ids. Sending both lists empty is how a restriction gets removed entirely, not a way to lock someone out.
PUT /admin/users/{user}/product-access
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
{
"user_id": 482,
"product_ids": [
118,
119,
204
],
"collection_ids": [
7
],
"scope": "restricted"
}200 Access updated
The detail almost nobody explains
An empty list is how you remove a restriction, not a mistake
Sending no product ids and no collection ids doesn't lock a user out of everything: it clears the restriction entirely and returns them to seeing every product in the organization, same as any other unrestricted teammate. Restricting someone to zero products isn't a state the system tries to represent as its own thing, on purpose, to avoid a separate, easy-to-misuse state that quietly means "see nothing".
Frequently asked questions
Yes, by assigning them to a collection instead of individual products. A product added to that collection afterward is visible to them automatically, with no need to go back and update anything.
Yes, for sensitive actions. Permissions get rechecked in real time against the same active session, so a revoked permission stops working immediately, not on their next login.
Yes. leads.view and support.view are two entirely separate permissions, so a role can be granted one without the other, keeping the two teams' inboxes apart even though both run through the same system.
Every product or collection id in a scoping change gets re-validated against what the organization actually has, and against the acting admin's own accessible products, before anything gets saved. A tampered payload with an id that doesn't check out simply gets rejected.
Twenty-eight, covering everything from managing users and rotating API keys to redeeming a single ticket at the door, each one grantable entirely on its own.
More bookings. More channels. The same calm.
Tiqory keeps availability, pricing, payments and access working together as your operation grows. Tell us where you are headed; we’ll show you how to get there without starting over.