LINE error 400: The property, XXX, in the request body is invalid

The reference documents this as: "An invalid property was specified in the request body. The specific property is displayed for 'XXX'." Unlike The request body has X error(s), which reports rule violations on values inside a structurally acceptable body, this message fires when the body contains a property LINE doesn't accept at that position at all - a misspelled key, a property from a different object type, or a field pasted at the wrong nesting level. The template even includes the line and column of your raw JSON, which makes it one of the few LINE errors you can trace to an exact byte offset in the payload you transmitted.

The line/column detail is a strong hint about how to debug it: don't inspect the object your code meant to send, inspect the serialized JSON that actually went over the wire. Serializers that include null fields, ORMs that leak internal attributes, and hand-merged dictionaries are the usual sources of stray properties. The error is deterministic - the same body fails identically on every retry - and nothing was sent or charged.

Because the Messaging API evolves, a property that is valid on one endpoint may be unknown on another (for example, options that exist for push but not for reply). Always check the specific endpoint's request-body table in the reference rather than assuming the property sets are identical.

{
  "message": "The property, messages[0].quickReplay, in the request body is invalid (line: 6, column: 8)"
}

Never hand-assemble Messaging API JSON in production paths. Use the official SDK builders or a schema (OpenAPI/JSON Schema) checked in CI, and configure serialization to drop unknown and null fields. When adopting a new property from the docs, confirm it exists on the specific endpoint you call - the request-body tables differ between reply, push, multicast, narrowcast, and broadcast.