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.

The Approved Models list is your organization’s top level whitelist of models. Every API request that Requesty routes for your organization is checked against this list, unless a narrower access list is attached to the group or API key making the request.
  • Compliance. Ensure only vetted models can be called from any API key in your organization.
  • Cost control. Keep expensive frontier models out of reach until you have explicitly approved them.
  • Curated UX. Members see only approved models when they pick a model in the dashboard or chat playground.
  • Predictable routing. Fallback chains and load balancing only consider approved targets.
Open Approved Models in the Admin Panel →

​
How the whitelist works

Approved Models is one list of model IDs that lives on the organization. When a request reaches the router, Requesty checks the model against this list and rejects anything that is not on it. If you need finer grained policies for specific teams or workloads, layer Access Lists on top. The resolution order is:
  1. If the API key has an access list, use it.
  2. Otherwise, if any group the key belongs to has an access list, use the union of those lists.
  3. Otherwise, use the organization Approved Models list.
  4. If the organization has not configured Approved Models, every model in the Requesty catalog is allowed.

​
Managing the list from the Admin Panel

Everything for Approved Models lives in Admin Panel > Approved Models. Admin Panel showing the Approved Models tab

​
Default state and quick starts

If nothing is configured, the banner at the top reads All models are available by default and every model in the Requesty catalog can be used. The same banner exposes one click presets for the most common policies. Quick start presets: EU Only, EU + ZDR, US Only, ZDR Only Click a preset to seed the list. You can adjust the result afterwards.

​
Filter and approve

Use the status chips (All, Approved, Not added, New) together with the Providers, Region, Data Policy, Capabilities, and Released filters to narrow the catalog to the models you want. Filtering by Region = EU and Status = New Region filter dropdown Select models with the checkboxes at the left, then use the action bar that appears at the bottom of the page to approve them in bulk. Bulk approving 118 EU models To remove models, switch the status filter to Approved, select the rows you want to drop, and use the same action bar. Bulk removing 6 approved models When you remove a model that is currently referenced in an access list, the dashboard warns you so you can update that list before the removal lands.

​
What members see

  • The Model Library and the Chat playground hide non approved models by default. Members can flip a toggle to preview the full catalog, but they cannot select a non approved model in a request.
  • Routing policies (fallback, load balancing, latency) only let you pick from the approved set.
  • GET /v1/models returns only the models the calling API key is allowed to use. If the key has an access list, only those models are returned. Otherwise the response falls back to the group list, then to the organization approved set. Tools that call this endpoint (Open WebUI, Claude Code, GitHub Copilot, Cursor, and others) will automatically show only the allowed models.

​
Model ID format

Model IDs in both the approved models list and access lists use the same provider/model format you pass in the model field of a chat completions request. Regional variants are distinct IDs (for example, vertex/anthropic.claude-sonnet-4-5 is different from anthropic/claude-sonnet-4-5).

​
Combining with groups and API keys

Approved Models is the floor that every other layer narrows. Some example shapes:
  • Broad org, strict prod. Approve all the providers your team is allowed to evaluate (say 50 models). Create an access list called Production with just two of them and attach it to your production API keys. Internal experimentation keys still see the full 50.
  • Region scoped team. Approve every EU model in Approved Models. Create an EU only access list with the subset that you guarantee for an EU customer and attach it to that customer’s group. Members of other groups still see the full approved set.
  • One agent, one model. Approve a generous set at the org level for humans. For an autonomous agent, attach a one model access list directly to its API key. The agent cannot escape to anything else even if its code changes.

​
Best practices

Start broad, narrow later

Approve everything you trust at the org level, then express stricter rules through access lists. This keeps the dashboard usable for everyone while still giving you tight control over production keys.

Review on every model release

When a new model lands in the Requesty catalog it is not approved by default. Review and approve it the same week it ships so your teams stay current.

Tag your access lists

Use clear names for access lists (for example, Production, EU only, Cheap fallbacks) so anyone debugging a 403 from the router can find the policy that blocked a request.

Audit what is in use

Use Usage Analytics to see which approved models are actually being called. Remove anything that has been unused for months.
  • Access Lists: reusable, named whitelists you attach to groups and API keys.
  • Groups: how to organize members and keys into teams that share an access list.
  • Fallback Policies: only approved models can be used as fallback targets.
Last modified on May 13, 2026