In this article
Verify compatibility per capability and version. One successful request does not establish support for an entire interface.
A compatible API is not one property verified by answering a greeting. A server may handle ordinary conversation while treating tools, empty values or stream completion differently. Keep engineering evidence in a matrix: capability, test conditions, observed outcome and implementation version. This record is useful before router integration and after an engine update.
Separate description from evidence
The public OpenRouter API describes the platform’s external requests and responses. It helps explain the client interface, but it is not a complete upstream-provider onboarding contract. Your adapter matrix must name the interface being compared. Integration approval remains a separate process, and a documentation example does not establish its outcome.
Record the review date, server version and enabled features beside the specification name. A link to a changing page without these details makes a later audit difficult. If a capability was checked through only one client, keep that limitation visible too.
Choose the matrix axes
Each row represents a capability: ordinary chat, streaming, tools or structured output. Columns describe request mode, expected structure, fixture and outcome. Do not equate accepting a parameter with applying it: a server can accept a field while ignoring its value.
The vLLM documentation lists supported interfaces and limitations separately. This illustrates why a detailed record is useful: a broad compatibility label is weaker than a tested list of exceptions. Each exception needs an expected outcome rather than an unstated assumption in the test runner.
Make one fixture reproducible
Suppose the test checks completion of a short streaming answer. Its input contains no secrets, output is bounded, and the runner records status, content type, event sequence and terminal marker. It tests structure rather than demanding identical prose on every run.
For the matrix row, save a fixture identifier, input hash and expected properties. For example, the response identifies the correct model, completion is observed, and usage appears in an allowed position. If one property fails, the row must not remain green merely because HTTP succeeded.
Distinguish four outcomes
Useful states are supported, unsupported, untested and model-dependent. The last two must not automatically become rejection or confirmation. Explain the dependency: tool parser, model artifact, backend or launch setting.
An OpenAPI description can express a schema, but does not execute tests. Connect document and result versions explicitly. After an adapter change, rerun affected rows and a small control set covering other capabilities.
Use the matrix as a release boundary
The deliverable is a file of observations and open questions rather than a universal compatibility promise. It separates adapter regressions from unsupported model capabilities. Do not transfer a positive result to another endpoint or version without checking its conditions.
The provider overview explains integration context, while served-model-name covers model identification. These checks complement the matrix while preserving the distinction between a working local server and confirmed integration with an external platform.