new-required-request-property

What this check detects

A new required property was added to the request body. A request that omits it is invalid under the new contract, so existing clients that do not send it break.

Add the property as optional instead, or give the server a defined behavior for the missing value. (Adding it as required with a `default` is reported separately but is breaking in the same way, a default is a server-side fallback, not a rule that makes an omitted required property valid.)

Example

The new "email" property is required. Requests that omit it were valid before and now fail.

How to handle this change

When oasdiff flags new-required-request-property, you have a few ways to respond:

• Find a backward-compatible alternative. Redesign the change so clients that followed the old contract keep working, and agree on the approach with whoever introduced it.
• Release it in a new API version. Keep the current contract and introduce the change in a new version, then deprecate the old one with a sunset date so clients have time to migrate.
• Accept it as a deliberate breaking change. Sometimes a breaking change is unavoidable, such as an urgent or security fix. Approve it knowingly, document it in your release notes, and tell affected clients. This should be the exception, not a routine way of working.

If oasdiff's verdict does not match your API's compatibility policy, you can also change how it treats new-required-request-property with a severity-levels file:

Put one rule per line; the level can be err, warn, or info, or none to disable the check entirely:

# severity.txt
new-required-request-property warn

Then pass it to oasdiff:

oasdiff changelog base.yaml revision.yaml --severity-levels severity.txt