Skip to main content
The models endpoint returns a list of all AI models currently available through Portrix, including their IDs, providers, and metadata. You can use this endpoint to build dynamic model pickers in your UI, verify that a model ID is correct before making a generation request, or filter the catalogue by provider to see what is available from a specific upstream source.

Endpoint

Request

No request body is required — this is a GET request. Include your Authorization header as with all Portrix API calls. Optional query parameter:

Response Fields

string
Always "list".
array
An array of model objects, one per available model.

Request Examples

Response Example

Retrieve a Single Model

To fetch metadata for a specific model, append its ID to the endpoint path. Forward slashes in the model ID must be URL-encoded as %2F.
Example:
cURL
Response:
If the model ID does not exist in the Portrix catalogue, the endpoint returns a 404 Not Found error. See the Errors reference for the error response format.

Using the Model List

Here are practical patterns for working with the models endpoint in your application: Filter by provider — use the ?provider= query parameter to narrow results when you want to present provider-specific options in a UI dropdown. For example, ?provider=google returns only Google Gemini models. Build a dynamic model picker — call the models endpoint at startup (or cache it with a short TTL) to populate a list of valid model IDs rather than hard-coding them. This means your application automatically reflects new models as Portrix adds them to the catalogue. Validate model IDs before requests — before sending a generation request with a model ID from user input, check whether it appears in the models list. This lets you surface a friendly “model not found” error in your UI before spending an API call. Check provider availability — if you notice elevated error rates from a provider, query the models endpoint to confirm the provider’s models are still listed. Portrix may temporarily remove models from the catalogue during a provider outage.
Cache the model list with a time-to-live of 5–15 minutes rather than calling the endpoint on every request. The catalogue changes infrequently, and caching reduces unnecessary overhead.