An additive change is not breaking unless a client validates strictly

Adding a field to a response is safe by convention and unsafe in practice, because some client somewhere is validating against a schema that forbids unknown properties.

{
  "type": "object",
  "properties": { "id": {}, "total": {} },
  "additionalProperties": false
}

// a client generated from this rejects your new field.

// so publish the rule, in the documentation, as a
// compatibility contract:
//   "clients MUST ignore unknown fields"
//   "clients MUST NOT depend on field ordering"
//   "we MAY add fields and enum values in a minor version"

Stating what may change is more useful than promising nothing will, because it tells a client author which assumptions are theirs to fix. Adding an enum value is the case that catches even well-behaved clients: a switch over known values now has an unhandled case, and whether that is your fault depends entirely on whether you said it could happen. A consumer-driven contract test is the only mechanism that actually verifies any of this.