Appearance
Versioning & Policies
The public API is a contract. This page spells out what we promise, what we reserve, and what has changed.
Rely on URL versioning
The API is versioned in the URL path: every endpoint lives under /v1.
Additive changes stay in v1. New fields on existing payloads, new endpoints, and new optional query parameters can appear in v1 at any time without notice. Write your integration to tolerate unknown fields: never fail on a key you don't recognise.
Breaking changes ship as a new version. Renaming or removing a field, changing a type, or changing an endpoint's semantics will only ever happen in a new version prefix (/v2). When a new version ships:
- v1 keeps running in parallel for at least 12 months.
- The deprecation timeline is documented here, in the changelog, before anything is switched off.
Version the player too
The embeddable player follows the same principle on its own axis:
https://embed.podcasterplus.com/player/v1.jsreceives backwards-compatible updates in place: visual refinements, fixes, and new optional attributes.- Breaking player changes ship as
/player/v2.js; existingv1.jsembeds keep working.
Embed codes copied from the dashboard always reference the current recommended version.
Reserved authentication scheme
v1 endpoints are keyless: you never need credentials to read published content, and that will not change.
For future endpoints that expose private data or accept writes, the following scheme is reserved:
Authorization: Bearer pp_live_xxxxxxxxxxxxxxxx # production keys
Authorization: Bearer pp_test_xxxxxxxxxxxxxxxx # test keysTwo things follow from the reservation:
- If you build a client library today, model authentication as an optional bearer token with the
pp_live_/pp_test_prefixes; it will slot in when keyed endpoints arrive. - Sending an
Authorizationheader to v1 read endpoints is harmless: it's silently ignored, never an error.
API keys do not exist yet; there is nothing to generate in the dashboard today.
Fair-use rate limits
The API and embed hosts are free to use, without published hard quotas, under a fair-use policy:
- Abusive or runaway traffic is rate limited at the platform edge, in front of the API. Expect
429responses if you hit the limits (they may not carry the API's JSON error envelope); back off and retry with jitter. - Responses are heavily cached (
Cache-Controlwithmax-age=60); honour those headers and useETag/If-None-Matchconditional requests instead of re-downloading unchanged payloads. Content changes at podcast-publishing cadence, so polling more than once a minute gains you nothing. - Embedding players on high-traffic sites is fine and expected; the player and its data path are built to be cached at the edge.
There is no SLA on the public API or embed hosts. They're built on the same edge infrastructure that serves PodcasterPlus RSS feeds and media, but we make no formal availability guarantee for third-party integrations.
Changelog
2026-07-06: v1 launch
Initial public release:
- Podcasts:
GET /v1/podcasts/{slug},GET /v1/podcasts/{slug}/episodes(cursor pagination),GET /v1/podcasts/{slug}/episodes/latest,GET /v1/podcasts/{slug}/episodes/{idOrSlug}. - Episodes:
GET /v1/episodes/{id}. - oEmbed:
GET /v1/oembedfor listen-page URLs, with discovery tags on listen pages. - Embeddable player:
<podcasterplus-player>web component atembed.podcasterplus.com/player/v1.js, plus iframe pages at/ep/{episodeId}and/latest/{podcastSlug}.