Models endpoint

The Gateway models endpoint exposes Ethen’s parsed catalog together with diagnostics about the underlying data. It is useful for discovery and integrity checks, but it is not proof that every returned model is configured or runnable.

The inspected GET handler does not require authentication and does not implement a strict OpenAI /v1/models response.

Use the models route as an integrity and discovery input, not as a final availability oracle. The parser diagnostics can explain why the catalog is unexpectedly small, duplicated, or missing required rows. The model records can then be cross-checked against runtime status and provider configuration before an application attempts execution. This two-stage interpretation is important because an unauthenticated catalog response may be healthy while a project still lacks credentials, provider permission, modality support, or a runnable route.

Endpoint

The verified catalog route is:

GET /api/gateway/v1/models

It returns the parsed model catalog together with diagnostics about the catalog source. The route is useful for discovery and data-quality inspection, not as proof that each returned model can execute in the caller’s project.

Use GET /api/gateway/v1/models to retrieve catalog data and parser metadata.

The endpoint path belongs in application prose or code rather than a product_links entry.

Its current behavior reflects repository implementation at the verification date and may need API-shape review before publication.

The models endpoint is a catalog inspection route. Its value is not limited to the model rows: the accompanying parser metadata can reveal schema drift, duplicate identifiers, missing required rows, or a mismatch between expected and observed headers.

The endpoint is GET /api/gateway/v1/models. Diagnostics include header matching, row count, parsed count, duplicate model IDs, and missing required rows.

Authentication

The inspected handler does not enforce authentication. That fact applies only to this route and version; it must not be generalized to chat completions, key management, logs, usage, or other Gateway surfaces. Clients should still avoid treating the endpoint as a source of secrets or project-specific provider credentials.

Because the handler is unauthenticated in the inspected implementation, its response is catalog-oriented rather than a project authorization decision. Runnable status still depends on project configuration and the separate runtime checks used by chat completions.

No authentication check appears in the inspected handler.

That absence applies only to this endpoint and does not alter the Bearer-key requirement for chat completions.

Do not infer anonymous access for logs, usage, key management, or provider execution.

Response envelope

{
  "data": [],
  "meta": {
    "csvPath": "...",
    "headerMatchesExpected": true,
    "rowCount": 0,
    "parsedCount": 0,
    "duplicateModelIds": [],
    "missingRequiredRows": 0
  }

The values above illustrate the verified envelope from the source bundle; clients must use the values returned by their deployment.

The inspected handler does not require a Gateway key. That is a route-specific implementation fact and should not be generalized into a claim that all model or Gateway metadata is public in every environment.

The response includes data and a meta object containing CSV path and parser diagnostics. No supported query parameters for filtering, sorting, or pagination were verified. A valid-looking prefix is not proof of a valid key; status, expiry, revocation, and scope checks still control acceptance.

The route is not a strict OpenAI /v1/models implementation. The endpoint is GET /api/gateway/v1/models.

Consumers should handle the response as two related results. The data collection contains model catalog records, while meta reports parser and catalog diagnostics such as whether a fallback source was used, how many rows were read and parsed, duplicate model identifiers, and missing required rows. Diagnostics are not model entries and should not be displayed as though they describe an individual model’s capability.

A clean catalog response still does not guarantee execution. Before using a record in chat completions, consider its runtime status and whether the project has an eligible provider route and required credentials. The inspected handler does not enforce authentication, but that fact applies only to this endpoint; it should not be generalized to key management, logs, usage, or model execution. No supported query parameters for provider filtering, capability filtering, pagination, or sorting were verified, so clients should perform any needed selection against the returned records without inventing a server-side contract.

Request

The handler is a simple GET operation in the inspected source. No request body, pagination token, provider filter, capability filter, or sort parameter is part of the verified contract. A client can request the route and inspect the complete returned object, then apply local presentation logic if needed.

Do not send project credentials or BYOK secrets in query parameters. The route’s current lack of authentication is not a reason to place sensitive configuration into the request.

The verified handler is a GET operation without a documented request body.

No stable query-parameter filtering contract is established in the source bundle.

Perform client-side selection only after validating which fields are present in the returned catalog records.

The request is a plain GET without a verified body or query contract. Avoid documenting provider filters, capability tabs, sort keys, pagination, or page-size parameters for this API route unless later source inspection adds them.

Response

Read the payload as two layers. data contains catalog records produced by the parser. meta reports information about the source and parsing process, including diagnostics that can explain incomplete or malformed input. Those diagnostics are operationally important: an empty or reduced catalog may indicate source or parser trouble rather than a legitimate absence of models. Runtime eligibility still requires separate provider and project checks.

Catalog diagnostics should remain available to operators even when application code consumes only the model records. Hiding meta can make duplicate IDs, missing required rows, or parser drift appear to be provider availability problems. Store or surface those diagnostics where catalog quality is monitored.

The top-level object contains data and meta. data holds catalog records. meta can report the CSV path, whether headers match the expected schema, source row count, parsed record count, duplicate model IDs, and the number of rows missing required values.

These diagnostics help distinguish an empty catalog from a parser or source problem. A zero-length data array with nonzero source rows or header mismatches should be investigated differently from a valid source that simply contains no matching entries.

The top-level response contains data and meta.

Diagnostics describe catalog parsing; they do not certify that a provider credential or runnable route exists.

Read data as the parsed catalog and meta as diagnostics about how that catalog was built. A successful HTTP response can still contain warnings or counts that deserve investigation before the catalog is trusted operationally.

For the initial test, use the response to inspect catalog integrity, then rely on runtime status and provider configuration before sending a chat request.

Filtering and selection

When building a selector, preserve the model identifier and any catalog status fields exactly as returned. Filtering for display should not erase diagnostic metadata or silently relabel a catalog-only model as runnable. The final execution check belongs to the authenticated chat route, where project-specific provider configuration and policy are available.

No filtering query-parameter contract was verified for this handler. Filter, sorting, capability tabs, provider controls, and runtime inspection belong to the product explorer rather than the documented HTTP request shape. Do not invent page sizes, cursors, provider query parameters, or capability parameters for the endpoint.

Model selection for execution happens later. A catalog record can still be catalog-only, missing a provider key, unsupported for a modality, or otherwise non-runnable. Use the chat route’s runtime status and provider diagnostics before treating a catalog ID as executable.

Use model status and provider readiness from approved product surfaces when deciding whether a discovered entry can execute.

Catalog-only, provider-configured, runnable, unsupported-modality, and missing-key conditions must remain distinct.

No server-side pagination size or filter syntax is verified for this endpoint.

Model selection requires more than a catalog identifier. Runtime status, provider configuration, credentials, policy, modality, and route eligibility determine whether a later chat-completion request can execute.

Attempt records remain relevant after a later success because the final provider field does not explain the entire route history. A successful catalog response can still contain models that are catalog-only, missing a key, or unsupported for a requested modality.

The endpoint is GET /api/gateway/v1/models. Request-level restrictions can narrow a project profile, but they cannot create provider support or override a policy exclusion.

Errors

The response’s parser diagnostics should be inspected even when the HTTP request succeeds. Header mismatches, duplicate IDs, missing required rows, or a difference between source and parsed counts can indicate catalog-data problems without producing a chat-style Gateway error code.

The route does not establish provider health, policy eligibility, budget, or credentials. Those failures appear only when an authenticated execution path evaluates the model.

An empty data array can reflect an empty or unparsed catalog rather than a valid model with zero availability.

Header mismatches, duplicates, and missing required rows belong to data-quality investigation.

If a chat request later fails, correlate the selected model with runtime-status errors instead of assuming endpoint discovery guaranteed execution.

Errors may appear as HTTP failure or as diagnostic evidence inside a successful response. Preserve the entire payload during catalog troubleshooting so parser problems are not reduced to an empty-model symptom.

The endpoint is GET /api/gateway/v1/models.

The inspected GET handler does not enforce authentication and does not expose a verified filtering query contract.