A podcast has several useful labels: a title, a publisher name, a feed address, and a catalog ID. They answer different questions. Treating them as interchangeable creates trouble when a publisher changes hosting or updates the show's name.
The catalog ID identifies the record in your provider's system. The feed URL tells a client where to retrieve publisher data. A title is display text. None of these should be rebuilt from another using string rules.
Store the relationship explicitly
Keep the provider name and its record ID together. Store the current feed address as metadata. If you later support a second provider, do not assume its numeric or string ID refers to the same show.
Follow relationships should use the identity your backend supports. A renamed show should not lose its listeners just because a search card now displays different words. Likewise, two shows with identical names must remain separate choices.
If your app creates public links, use a stable internal identifier and an optional readable slug. Look up the record by the stable part. Treat a slug as a label that can change, not as proof of identity.
Test a hosting move
Create a fixture where one record keeps its ID while the feed address changes. Existing subscriptions and saved links should still open the same show. Then create two records with the same title and verify that each remains distinct.
Avoid automatically merging records solely because their feed URLs or artwork match. A migration can require a deliberate reconciliation rule and human review.
Podnivo's catalog guide tells clients to treat IDs as opaque values. Following that rule keeps your integration flexible when the catalog evolves.