LINE error 400: invalid_client (invalid client_id / client_secret)

Issuing a short-lived channel access token (POST /v2/oauth/accessToken) failed because the credentials you exchanged are wrong. The endpoint's documented examples are {"error": "invalid_client", "error_description": "invalid client_id"} when the channel ID is invalid and {"error": "invalid_client", "error_description": "invalid client_secret"} when the channel secret is invalid; the error table adds a third possibility, "the request parameters are in the wrong format" - this endpoint takes application/x-www-form-urlencoded parameters, not JSON.

The distinction from The access token expired matters: that error is about a token you already had; this one means you never got a token because the channel ID/secret pair didn't authenticate. The usual root causes are credential mix-ups rather than typos: the channel secret from a different channel (a LINE Login channel instead of the Messaging API channel, or staging instead of production), a secret that was reset in the LINE Developers Console while deployments still carry the old value, or a form body that was accidentally JSON-encoded so the parameters never parsed.

For the v2.1 endpoint (JWT assertion flow), the equivalent failures are documented as the JWT assertion failing verification or having expired, plus a 404 when the signature key isn't registered in the channel - same category, different mechanics.

// If you specify an invalid channel ID (400 Bad Request)
{
  "error": "invalid_client",
  "error_description": "invalid client_id"
}

Keep channel ID and secret as a paired secret in one store entry so they can't drift apart, and label them by channel type and environment - the "wrong channel's secret" failure is almost always a labeling problem. Rotate deliberately with a two-step deploy (issue new, switch, revoke old), and monitor the issuance endpoint's 370-requests-per-second rate limit only if you mint tokens per request, which you shouldn't.