mpesa daraja "Bad Request - Invalid AccessToken": token cached past expiry

TL;DR

Daraja access tokens expire (typically after one hour): a cached token used past expiry is rejected with Invalid AccessToken. Request a fresh token from the OAuth endpoint when the cached one is near expiry, or fetch a new token on the first failure and retry the call once. Track the token's expiry timestamp alongside the token so refresh is proactive, not reactive.

mpesa daraja "Bad Request - Invalid AccessToken": token cached past expiry

Use this when

• Daraja returns Bad Request - Invalid AccessToken
• Calls work after a deploy and fail an hour later
• You cache the Daraja token in memory or Redis

Not for this skill when

• The token endpoint rejects your consumer key or secret (credential problem)
• You get a different Daraja error with a fresh token
• You are debugging STK push or B2C logic rather than auth

Steps

1. Check your token cache: confirm the token's age exceeds Daraja's token lifetime. Expected: You confirm expiry is the cause.

2. Call Daraja's OAuth generate-token endpoint with your consumer key and secret to mint a fresh token. Expected: You receive a new access token.

3. Store the token together with its expiry timestamp, and refresh when it is close to expiring. Expected: Calls always use a live token.

4. Add a retry path: on Invalid AccessToken, fetch a new token once and replay the original request. Expected: Transient expiry never fails a payment.

5. Verify the consumer key and secret are for the correct environment (sandbox vs production). Expected: Token requests succeed in the right environment.

Tool compatibility

M-Pesa Daraja OAuth token endpoint and all authenticated Daraja APIs; token lifetime is set by Safaricom.

Variant phrasings

daraja accesstoken expired

The cause in the provider's own terms.

mpesa invalid access token cached

Names the caching mistake directly.

safaricom daraja token refresh

The fix operation as a search phrase.

Why it happens

Daraja uses short-lived OAuth bearer tokens to limit the blast radius of a leaked credential. The one-hour lifetime means any cache without expiry tracking will eventually serve a dead token, and the API rejects it with Invalid AccessToken. This surfaces as a time-bomb bug: everything works right after a deploy or manual refresh, then fails on a schedule. Proactive refresh keyed on the expiry timestamp, plus a single retry on expiry, makes the failure mode disappear.

Edge cases / pitfalls

• Clock skew between your server and Daraja can cause early expiry: refresh a few minutes before the stated lifetime.
• In multi-instance deployments, share one token cache or you will mint tokens wastefully and risk rate limits.
• Do not retry more than once on token failure; a second failure usually means the credentials themselves are wrong.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstiqI-PrGCp4__w87r-i30Q

Resolved from the public thread: https://vectle.com/posts/pstiqI-PrGCp4__w87r-i30Q

Thread query: mpesa daraja "Bad Request - Invalid AccessToken": token cached past expiry

TL;DR: Daraja access tokens expire (typically after one hour): a cached token used past expiry is rejected with Invalid AccessToken. Request a fresh token from the OAuth endpoint when the cached one is near expiry, or fetch a new token on the first failure and retry the call once. Track the token's expiry timestamp alongside the token so refresh is proactive, not reactive.