In this article
Missing values, null and empty containers have different semantics. Transform them only under an explicit interface contract.
API tests often use only a fully populated user message. That input reveals little about missing content, explicit null or an empty tools array. Normalization mistakes can change request meaning before model execution. Providers need a separate contract area describing valid combinations of role, content and additional fields, followed by checks against the actual interface.
Keep four representations separate
A field can be absent, contain null, contain an empty string or contain an empty array. These are different JSON values and object structures. The public OpenRouter schema describes particular message and response shapes, but does not authorize every field combination for an arbitrary engine.
State allowed variants per role in your own contract. A message containing tool calls, for example, needs a different fixture from an ordinary text turn. If an adapter automatically fills omissions, give that transformation a separate rule and test.
Record schema rules
JSON Schema distinguishes an absent required property from a property whose value is null. Listing properties does not make every field mandatory. A local validator therefore needs the exact comparison schema rather than an approximate object copied from an example.
Check additional properties and nested objects separately. Removing an unfamiliar field does not establish that the original request was fully supported. Define the chosen policy, its scope and the response callers receive when it is violated.
Build a compact fixture set
Take one base request and create variants changing one condition: remove content, set content to null, make content empty, or make tools empty. Define the expected classification in advance: acceptance, explicit rejection or documented transformation.
Save fixture ID, original body and observed response shape. Passwords, internal addresses and real user conversations are unnecessary. Save the adapter version as well: a normalization change may appear only after a dependency update.
Check before and after adaptation
Where an internal test boundary is available, compare client input with the request passed to the engine. This separates schema errors, unsupported roles and chat-template behavior. Without that boundary, conclusions remain limited to external observation; state that in the report.
RFC 8259 defines JSON syntax rather than application-level model-message correctness. A valid document is not necessarily an allowed request. Likewise, successful parsing does not prove an empty turn preserved its intended meaning after transformation.
Preserve differences in release tests
After changing a validator, repeat the complete small set rather than only the base example. Rejection replacing earlier transformation can be an intentional contract change, but it must appear in release notes and expected results. Unintentionally collapsing all empty states into one value warrants investigation.
The first Python request explains request context, and the tool-calling guide covers tool messages. Those instructions show interface use; fixtures establish precise boundaries. Neither proves that an external platform has approved a provider.