A workspace key and a listener token should not be treated as two names for the same password. They represent different callers and different boundaries.
Your application server may need access to a workspace's catalog and listener operations. A public client should receive only the authority it needs for one authenticated person. Podnivo documents a listener-token flow for that purpose.
Start with the caller
The browser or mobile app first signs in to your own application. Your backend then maps that account to the external listener ID used by the podcast service. Do not let the client choose an arbitrary ID and receive a token for it without checking ownership.
Keep the workspace key in server-side secret storage. Use it only in the backend operation that mints or manages the documented listener credential. Return the listener token through an authenticated response with suitable cache controls.
A short lifetime reduces the useful window of an exposed token, but it does not remove the need for secure storage and transport. Avoid printing tokens in crash reports or app analytics. Do not assume a token's readable fields are trustworthy without the server's normal verification.
Test the boundary with two accounts
Create two controlled listener accounts in the same test workspace. Confirm that one listener's credential cannot read or write the other's state. Repeat the test across two workspaces as well.
Test expiration separately from an invalid token. The client needs a sensible recovery path for each, such as asking its backend for a fresh credential or returning to sign-in.
Read the current Podnivo contract for token lifetime, claims, and endpoint scope. Design around those documented rules rather than a token's apparent shape.