A listener stops an episode on a phone and opens a laptop. Where should playback start? This small question needs a clear rule. Saving one number is only the first step.
Save position, not just time spent listening
Playback position means the point in the audio. Listening time means how long someone listened. These values can differ. A listener may move back to hear a sentence again or skip a long introduction.
For example, a person can listen for ten minutes and end at minute twenty after a skip. Do not use those ten minutes as the resume position.
Use the same episode identity
Every device needs to refer to the same episode. Keep your app's internal ID separate from the title and audio file address. When importing feeds, remember that an episode GUID is intended to stay stable. A file URL alone is a weak basis for your own resume key.
Decide how old updates behave
An offline phone can send an old position after a laptop has saved a newer one. Write down which update wins. Do not simply keep the largest position: that would stop a listener from moving back on purpose.
One possible design uses a server revision. The client sends the revision it last saw. The server can reject an update that would replace newer state and ask the client to load it again. HTTP conditional requests provide a standard way to express this kind of check, but you must confirm whether your API actually supports it.
Test the uncomfortable cases
Use one episode and two devices. Test pause and resume, an intentional backward seek, an offline update and a repeated request. Also decide what “mark as played” means when the listener later starts the same episode again.
Keep test logs free of real listener names and private tokens. A small test account is enough to check these rules.
Podnivo is prelaunch. Explore its podcast app backend plans and compare the published contract with the sync rules your app needs.