In this article
An accepted field is not necessarily applied. Make unsupported-parameter policy explicit and test it separately from prose quality.
An unsupported parameter creates two different problems. A client may receive an immediate error, or a formally successful answer produced with different settings. The second is harder to notice because the caller believes the constraint was applied. Providers need an explicit policy separating syntactic acceptance, feature support and observable effect.
Name the interface being tested
The OpenRouter parameter documentation describes its external API and notes that omitted sampling fields are not replaced with universal hardcoded settings. This does not establish that every upstream must accept all fields or choose defaults identically. An adapter needs a documented support boundary for its specific version.
Record where client, router and engine responsibilities meet. If a field is transformed between layers, observe that transformation separately. Otherwise a missing effect can be blamed on the model when the parameter disappeared earlier.
Distinguish valid policies
One option is explicit rejection identifying the unsupported capability. Another is documented ignoring where the interface defines that behavior. A third is support limited to certain models. None should be hidden behind a general compatibility label.
The vLLM documentation includes concrete interface and parameter exceptions. It illustrates precision rather than prescribing behavior for every server. Check another engine independently; do not transfer one implementation’s exception into another’s description without evidence.
Test acceptance separately from application
Create a small fixture containing one disputed field. First inspect response status and structure. Then establish whether the parameter reached the relevant layer and affects the claimed property. For a numerical sampling parameter, one attractive answer is not reliable proof of application.
A useful artifact contains the original request, expected policy, observed outcome and adapter-boundary evidence. Secret headers do not belong in that record. If observation is limited to a black box, state which conclusions remain unproved.
Add negative variants
Test an unknown field, a known field with the wrong type, and a known field against a model lacking the capability. Their rejection causes can differ. Do not merge them into one vague parameter error when clients need to distinguish fixing request shape from selecting another capability.
JSON Schema separates object properties, required fields and additional-property restrictions. A schema can express the chosen policy but cannot establish implementation. Include a real endpoint check rather than testing only a local validator.
Preserve exceptions across updates
After a version change, compare supported, ignored and rejected parameters. Unexpected ignoring can be a regression even when HTTP status stays unchanged. Update documentation and expected fixtures together when policy changes.
Router-specific behavior is covered in provider selection, while vLLM installation compatibility covers the engine environment. Separating these layers supports precise claims without inventing onboarding requirements or suggesting that an external integration is already operational.