Document the model catalogue API (GET /v1/models) - #488
Merged
Conversation
`GET /v1/models` serves ~1.2k requests a day and was not documented anywhere: no page in this repo, no Swagger decorators on the handler, so nothing in Scalar either. Its whole query surface — `include`, `details`, `id`, `type`, `tags`, `modalities`, `input_modalities`, `output_modalities`, `capabilities` — existed only in a JSDoc comment in the gateway. Adds the page, an OpenAPI spec for the operation, and a SUMMARY entry. Covers the two things integrators get wrong: matching a model against `id` alone instead of `id` + `aliases`, and comparing `price` without `per`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
GET /v1/modelsserves roughly 1.2k requests a day and is documented nowhere: no page in this repo, and no Swagger decorators on the handler, so it is absent from Scalar too. Its entire query surface lives in a JSDoc comment in the gateway.The practical cost: a customer (Help Scout #8265) has been maintaining our prices by hand and polling the deprecated-models HTML page, because nothing told them
?include=pricingexists — or that?id=<model>&include=pricinganswers in ~4 KB instead of 1.3 MB.What this adds
docs/api-references/service-endpoints/models-catalogue.md— the pagedocs/service-endpoints/models-catalogue.json— OpenAPI spec for the operation, same pattern asbilling-balance.jsonSUMMARY.mdentry under Service Endpoints, next to Account BalanceWhat it documents
Every parameter, with the semantics verified against production:
include(pricing/modalities/capabilities/all) anddetailsas its synonym; unknown values ignored, not rejectedid,type,tags,modalities,input_modalities,output_modalities,capabilitiesinclude— you can filter on capabilities without requesting that sectionPlus the two things integrators actually get wrong:
idalone. A model can be published under a canonical id while the name someone integrated against lives on as an alias — it still serves, but anid-only comparison reports it as gone. The page gives the alias-map snippet.pricewithoutper.peris1000000for most token rates,1000for some,1for per-second and per-megapixel ones. Comparing barepriceis wrong by orders of magnitude.Also covers how to read
pricing.kind(fixed/variants/variable) and theETag/If-None-Matchflow, with the caveat that the ETag covers the whole body — it is a "something changed, re-read and diff" signal, not a price feed.Checked
The JSON parses. Every example — parameter names, filter behaviour, response shapes, the ETag round-trip, the per-second variant sample — was run against
api.aimlapi.comrather than written from the source.Note
There is no docs preview environment to check this in: the
stagingbranch here last moved in May 2025 and is 2331 commits behindmain, and no GitBook preview is wired to PRs. Rendering is worth a look after merge.