What this error means

Spectral's built-in oas3-schema rule checks your document against the OpenAPI meta-schema. When it finds a property that is not allowed at that position, it reports Property "X" is not expected to be here, where X is whatever keyword you placed wrong. The keyword is almost always legal somewhere in OpenAPI, just not at the nesting level where it sits.

Why Spectral emits it

Three causes account for nearly every occurrence:

• Swagger 2.0 keywords in a 3.x document. produces, consumes, definitions, host, and basePath were all removed in OpenAPI 3.0. Specs migrated by hand tend to carry a few of them along.
• A keyword one level off. schema directly under a response instead of inside content, or required: true written inside a schema property instead of the schema's required array.
• A typo in a keyword name. responces or parameteres is an unexpected property as far as the meta-schema is concerned.

Here is the migration case, the most common one. The document declares OpenAPI 3.0 but keeps a 2.0 produces block:

In OpenAPI 3.x, the response media type lives in a content map keyed by MIME type, one per response. The same move applies to consumes: it becomes the content map of a requestBody.

When the flagged property is not a 2.0 keyword, read the line above it. Spectral reports the property, but the mistake is usually the parent it landed under. Fix the indentation or move the keyword to the object that actually accepts it.

How to catch it earlier

Since this class of error comes from hand-editing, the fastest check is structural validation on every save. The free OpenAPI validator reports unexpected properties with their exact path, and the OpenAPI linter runs the same Spectral-style ruleset in the browser, so you see the error before CI does. Migrating a 2.0 spec wholesale? Convert it mechanically first instead of editing keywords by hand.

Frequently asked questions

Which Spectral rule produces this message?

oas3-schema for OpenAPI 3.x documents, oas2-schema for Swagger 2.0. Both validate against the meta-schema for the declared version, which is why the same document can pass as 2.0 and fail as 3.0.

Why is produces not allowed in OpenAPI 3.0?

OpenAPI 3.0 replaced produces and consumes with per-response and per-requestBody content maps. Any document declaring openapi: 3.0.x gets the 3.0 meta-schema, and the 2.0 keywords fail against it.

The property it names looks valid. Why the rejection?

It is valid, elsewhere. schema belongs inside a media type object, not directly under a response; example belongs on a schema or media type, not on a response. Check the parent object of the flagged line.