Problem Details, and an error format that is not invented here

Every API invents an error envelope, and RFC 7807 is a perfectly good one that client libraries already understand.

HTTP/1.1 422 Unprocessable Entity
Content-Type: application/problem+json

{
  "type": "https://example.com/probs/insufficient-stock",
  "title": "Insufficient stock",
  "status": 422,
  "detail": "Only 2 of SKU ABC-1 remain.",
  "instance": "/orders/8814",
  "available": 2
}

type is the field a client should branch on and it is a URI rather than a string code, which makes it globally unambiguous and documentable by being dereferenceable. title is for a human and must not be parsed; detail is specific to this occurrence. Extension members like available are explicitly allowed, which is what makes the format usable for real errors rather than only generic ones. The content type matters, because it is how a client knows to expect this shape.