Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.requesty.ai/llms.txt

Use this file to discover all available pages before exploring further.

Access lists are reusable, named collections of model IDs that you create once at the organization level and then attach to groups and API keys. They let you express policies like “Engineering can use GPT and Claude reasoning models” or “Production agent keys can only call our two cheapest fallback models” without duplicating the model list across every key. Common use cases:
  • Per team policies. Attach a list to a group so every member inherits the same model whitelist.
  • Per workload policies. Attach a stricter list to a single production API key while leaving exploratory keys open.
  • Compliance. Restrict keys or groups to models that meet your data residency or vendor requirements.
  • Cost control. Block expensive frontier models from low priority workloads.
Open Access Lists in the Admin Panel →

​
Create an access list

Everything for access lists lives in Admin Panel > Access Lists. Each list card shows how many groups and API keys it is currently attached to, plus a preview of the models it contains. Access Lists tab in the Admin Panel Click Create Access List in the top right. Give the list a descriptive name (for example, Production agents, Reasoning only, EU residency) and tick the models to include. You can search by provider or model name and use Select all to grab every model in a provider section in one click. Create Access List modal Click Create to save. The list is now available to attach to any group or API key in your organization.
An access list lives at the organization scope. The same list can be attached to many groups and many API keys at once. Updating the list updates the policy for every attached resource.

​
Edit, duplicate, or delete a list

From the card on the Access Lists page:
  • Edit the name and the set of models. Changes take effect immediately for every group and API key that has this list attached.
  • Duplicate the list to use it as a starting point for a new policy.
  • Delete the list. Any group or API key that had this list attached falls back to the next layer (group list, then organization approved models).

​
Attach an access list to a group

When an access list is attached to a group, every API key that belongs to that group inherits the list (unless that API key has its own access list, which overrides the group). In Admin Panel > Groups, expand the group you want to restrict. Each group has an Access List section. Click Manage, pick one of your access lists from the dropdown (or None to clear it), and save. The change applies on the next request through any API key in this group.

​
Attach an access list to an API key

You can attach an access list when you create a new API key, or attach (or change) one later on an existing key. A list attached directly to a key overrides any group list, so use this when you want a single workload (for example, a production agent) to be more restricted than the rest of the group. When creating a key. Go to API Keys, click Create API Key, and pick a list in the Access List field. Leave it as No access list (no model restrictions) if you do not want to restrict the key. On existing keys. In the API Keys page, select one or more rows. The bulk action bar at the bottom of the page lets you pick an access list from the dropdown and click Attach. Attaching the same list to many keys at once is the fastest way to roll out a new policy. Bulk attaching an access list to API keys from the Admin Panel
Detaching an access list from an API key does not open the key up to every model. It falls back to the group list, and then to the organization Approved Models, in that order.

​
How tools see your access list

GET /v1/models returns only the models the calling API key is allowed to use. When you attach an access list to a key, any tool that fetches the model list will automatically show only the allowed models. This includes Open WebUI, Claude Code, GitHub Copilot, Cursor, and any other client that calls the models endpoint. For example, if you create an access list with just two models and attach it to a key, pasting that key into Open WebUI will show exactly those two models in the model picker.

​
Resolution order

Requesty resolves the approved set of models for a request using three layers. The most specific layer that has a non empty list wins:
  1. If the API key has an attached access list, only models in that list are allowed.
  2. Otherwise, if any of the groups the key belongs to has an attached access list, the request is allowed if any of those group lists include the model.
  3. Otherwise, the organization wide Approved Models list is used.
  4. If nothing is configured at any level, every model in the Requesty catalog is allowed.
When a request asks for a model that is not on the resolved list, the router returns a provider violates policy error and does not forward the request to the upstream provider.

​
Multi group keys

An API key can belong to a group, and an organization member can belong to multiple groups. When resolving the allowed set, Requesty takes the union of the lists attached to the groups that own the key. If a group has no list attached, that group does not narrow the policy. This makes it easy to give a user a base permission set from one group and add additional capabilities through a second group.

​
Examples

  • Tighten one production key. Engineering has a group with no access list, so every key in that group falls back to Approved Models. You attach a Production access list with just two models to one specific production API key. That key is now restricted to those two models; every other engineering key still sees the full org list.
  • Two groups, one user. A user is in both Engineering (access list of 10 models) and Research (access list of 4 models, two of which overlap). A key owned by that user with no access list of its own can use the union: 12 models. Adding Production directly to the key reduces it to whatever is in Production.

​
Model IDs in access lists

Models are stored in an access list using their canonical Requesty model ID in the form provider/model, the same format you use in the model field of a chat completions request. Example IDs:
  • openai/gpt-5
  • anthropic/claude-sonnet-4-5
  • google/gemini-2.5-pro
  • vertex/anthropic.claude-sonnet-4-5
You can look up the exact IDs for the providers and regions you care about in the Model Library. The same IDs are returned by GET /v1/models on the router.
If you list a regional variant (for example, vertex/anthropic.claude-sonnet-4-5) and a request comes in for a different region of the same family, the request is rejected. Add every variant you want to allow to the list.
  • Approved Models: the organization wide whitelist that access lists narrow further.
  • Groups: how to organize members and API keys into teams that share an access list.
  • API Limits: per key and per group budgets that work alongside access lists.
  • EU Routing: tag the models you allow with their geolocation when building region scoped lists.
Last modified on May 13, 2026