LINE error 400: The request body could not be parsed as JSON

LINE's parser gave up before validation even started: "The JSON in the request body could not be parsed. The specific line and column are displayed." This is a lower-level failure than The request body has X error(s) - there, your JSON was syntactically valid and individual values broke rules; here, the bytes you sent are not valid JSON at all. The line and column in the message point at the position where parsing failed in the raw request body.

Almost every occurrence is a transport or templating bug rather than a content bug. Shell scripts with unescaped quotes in curl -d, string-concatenated JSON with a trailing comma, double-encoded bodies (a JSON string containing JSON), truncated payloads from a client timeout, and templates that interpolate user text containing " or newlines without escaping are the classics. Note the adjacent failure modes: if the body is valid JSON but the header says something other than application/json, you get The content type, XXX, is not supported; if the body is valid JSON with a bad field, you get the validation error with a details array instead.

The error is deterministic and free - nothing was delivered, no quota was consumed, and retrying the identical bytes will fail identically. Fix the serialization, not the schedule.

{
  "message": "The request body could not be parsed as JSON (line: 4, column: 21)"
}

Ban string-built JSON in code review; every Messaging API payload should pass through a real serializer and, for message objects, the free validate endpoints in CI. Escape-test your templates with hostile input ("quotes", newlines, emoji) since user text eventually contains all of them. Keep one shared HTTP client that always sets Content-Type: application/json and serializes centrally - it removes this entire error class along with content-type mismatches.