Skip to main content
A podcast lives in many places: it’s on Apple Podcasts and Spotify, the host posts to X, the publisher runs a YouTube channel, and there’s a marketing site on its own domain. The external-links endpoint returns every one of those presences in a single, normalized shape — with the platform-native identifier, a ready-to-use web URL, and a list of optional per-platform attributes (subscribers, followers, handle, etc.).
This page is the forward index: given a Particle podcast, list every third-party identifier we have for it. To go the other way — given an Apple, Spotify, or YouTube identifier, find the matching Particle podcast (in bulk, deterministically) — use GET /v1/podcasts/lookup.
Use this endpoint when you want to:
  • Build a “follow this podcast on…” UI without hard-coding per-platform URL templates.
  • Compare audience size across platforms (Spotify followers vs. YouTube subscribers vs. Castbox subscribers).
  • Pull the publisher’s website and social handles for outreach or research.
  • Reconcile a podcast across third-party catalogs (Apple ID ↔ Spotify show ID ↔ Podchaser ID). If you start with the third-party identifier instead, use GET /v1/podcasts/lookup — it’s the reverse direction of this same index.
The path parameter accepts a slug (hard-fork, all-in), the internal podcast ID, or a numeric Apple/iTunes collection ID — same as every other podcast sub-resource.
Response (truncated)
Per-podcast cardinality is bounded — at most one entry per platform — so the endpoint returns the full set in a single response by default. Pass ?limit= and ?cursor= if you specifically want to page through results.

Anatomy of an entry

Every entry has the same shape regardless of platform. Optional fields are omitted when no data is available.

Platform types

platform.type lets clients render related platforms with a shared treatment without knowing the full list of names:

Attributes

Each entry’s attributes is a list of typed records. The set of attribute names that may appear varies per platform — and grows over time as upstream sources expose richer metadata. Clients should treat unknown attribute names additively rather than enumerating them.

Attribute categories

Platform reference

The full list of platforms surfaced today, with the URL templates the API uses to build the url field. New platforms may be added without notice; existing platform names are stable.

YouTube: richer attributes

YouTube is currently the most heavily-enriched platform. A YouTube entry can carry up to four attributes today:
The display_name, thumbnail_url, and founded attributes may also appear when known.

Notes and gotchas

apple and itunes are usually duplicates

Apple Podcasts uses a single numeric ID across both its modern and iTunes-era surfaces. Most podcasts therefore have two entries — apple and itunes — with the same identifier and the same resolved url. This faithfully reflects what upstream catalog sources report; clients that want a single Apple entry can de-duplicate by (type, identifier).

Attributes are forward-compatible

Both attributes[].name and attributes[].category are open enumerations. New names (e.g. a future engagement_rate for Instagram) and new categories will be added without a versioning event. Always render unknown attributes additively — match on category for grouping when the name isn’t recognized.

observed_at is best-effort

Some attributes don’t have a known observation timestamp; the field is then omitted. When present, the timestamp reflects the last time the value was refreshed from the upstream source — not the last time the podcast itself was updated.

Identifier formats vary

The identifier is whatever the platform natively uses. Examples: The website platform is the exception: there’s no separate identifier — the entry omits identifier entirely and only carries url. If you need a clickable link, prefer the resolved url over building one yourself; URL templates change.

Choosing the right endpoint