LINE error 400: The access token expired

This one comes from LINE's token endpoints rather than the messaging endpoints, and it uses the OAuth-style error shape - error plus error_description - instead of the usual message body. When you verify a channel access token v2.1 with GET /oauth2/v2.1/verify and the token's lifetime has run out, the documented example response is 400 Bad Request with {"error": "invalid_request", "error_description": "The access token expired"}. The same endpoint family returns "The access token not JWS" for an invalidly formatted token, and the verify endpoint's error table adds a third case: "a non-existent channel access token is specified" - i.e. one that was revoked.

Practically, this error is the explicit version of what the messaging endpoints report as 401 Authentication failed: an expired or dead token. The difference is where you catch it. Verifying tokens proactively (or checking expiry from your own issuance records) lets you rotate credentials before message sends start failing. Channel access tokens v2.1 have a lifetime you choose at issuance (up to 30 days), short-lived tokens last 30 days and are capped at 30 issued tokens per channel, and stateless tokens live 15 minutes but can be issued without limit - so every architecture needs a reissue path, not a fix-once mindset.

// If the channel access token has expired (400 Bad Request)
{
    "error": "invalid_request",
    "error_description": "The access token expired"
}

Automate issuance and rotation instead of minting tokens by hand: schedule reissue at a safe fraction of the token lifetime, store tokens in a secrets manager, and run a daily verify call that alerts on anything close to expiry. Stateless tokens (15-minute lifetime, unlimited issuance) remove the storage problem entirely for services that can fetch a token per burst of work. Keep 401 handling as the runtime backstop.