Do I need token refresh handling in my push backend?

Usually yes—if your push backend stores and uses push credentials that can expire or be rotated, you should have some form of token refresh / credential renewal handling.

It depends on what you mean by “token”:

1) If you mean OAuth / access tokens for calling the push provider API

Then yes, definitely.
Examples:

• FCM HTTP v1 uses Google OAuth2 access tokens
• Some vendor APIs use short-lived bearer tokens

In that case your backend should:

• obtain tokens before they expire
• cache them
• refresh them proactively
• retry on auth failures if needed

2) If you mean device registration tokens / push tokens

Then it’s not “refresh” in the OAuth sense, but you still need token lifecycle handling.

For example with push services:

• device tokens can change
• tokens can become invalid after app reinstall, logout, app data clear, APNs/FCM changes, etc.
• sends may fail with “not registered”, “invalid token”, “unregistered”, etc.

Your backend should:

• remove invalid tokens when the provider says they’re dead
• update stored token mappings when the client reports a new token
• handle duplicates and token rotation

Practical rule

Your push backend should handle:

• provider auth token refresh if it talks to push APIs
• device token invalidation/rotation if it stores recipient tokens

If you do not need it

You might skip explicit refresh handling only if:

• your push library/provider manages auth internally, and
• you don’t store long-lived device tokens yourself, or the provider abstracts that away

But in most real backends, some token handling is needed.

If you want, I can tell you the exact answer for FCM, APNs, or Web Push specifically.