New Podcast service listing

[bcordis]

Look at adding all the podcast services as an add-on option with fill-in data.

May look at a generic one that someone can fill in the data.

Podcast Supporter Platform API Hooks

---

PRIMARY PLATFORMS

1. Apple iTunes/Apple Podcasts

Webhook Support: ❌ NO

• API Available: Yes - iTunes Search API
• Capabilities:
  • Search podcasts by title/artist
  • Lookup podcast details
  • Retrieve RSS feed URLs
  • Episode information (via RSS parsing)
• Limitations:
  • Read-only directory API
  • No native webhooks
  • No real-time notifications
  • Must poll RSS feeds for updates
• Authentication: None required (public API)
• Rate Limiting: Not explicitly documented
• Best For: Discovery and metadata lookup only

Alternative Strategy: Use RSS feed polling or third-party aggregators with webhook support (e.g., Taddy API)

---

2. Spotify Web API

Webhook Support: ❌ NO (Currently)

• API Available: Yes - Spotify Web API
• Capabilities:
  • Search shows and episodes
  • Retrieve podcast metadata
  • Get show/episode details
  • Access episode transcripts (where available)
• Limitations:
  • No webhook/push notification system (long-requested by developers)
  • Polling required for updates
  • Rate limiting applies per user/app
• Authentication: OAuth 2.0 required
• Rate Limiting: Varies based on plan (strict limits apply)
• Best For: Read-only podcast metadata and search

Community Request Status: Multiple GitHub issues requesting webhook support (no official timeline)

---

3. Google/YouTube

Webhook Support: ✅ YES (via PubSubHubbub)

• API Available: Yes - YouTube Data API v3
• Capabilities:
  • Real-time push notifications via PubSubHubbub
  • Subscribe to channel feed changes
  • Monitor video uploads, title/description updates
• Webhook Events:
  • New video upload
  • Video title update
  • Video description update
• Implementation:
  • Requires Google hub subscription
  • HTTP callback server setup needed
  • Atom feed format notifications
• Authentication: OAuth 2.0 (YouTube Data API)
• Best For: Video podcasts and YouTube channel monitoring

Setup Required:

1. Set up HTTPS callback endpoint
2. Subscribe via Google hub with callback URL
3. Receive Atom feed notifications in real-time

Documentation: https://developers.google.com/youtube/v3/guides/push_notifications

---

PODCAST HOSTING PLATFORMS

4. Acast

Webhook Support: ✅ YES

• Capabilities:
  • Episode publication notifications
  • Episode updates
  • Real-time event triggers
• Webhook Setup:
  • Located in Promotional Tools tab
  • Enable webhook switch
  • Provide server endpoint URL
• Event Format: JSON POST request
• Example Payload:

  {
    "event": "episodePublished",
    "id": "episode_id",
    "title": "Episode Title",
    "status": "published",
    "publishDate": "2020-01-13T21:57:57.768Z",
    "coverUrl": "https://...",
    "audioUrl": "https://..."
  }

• Publishing API: Also available for querying shows/episodes
• Rate Limiting: 60 requests/minute
• Best For: Tight integration with publishing workflow

Integration Options:

• Direct webhook implementation
• Zapier integration available

---

5. Buzzsprout

Webhook Support: ⚠️ LIMITED/API-BASED

• API Available: Yes - REST API with GitHub documentation
• Capabilities:
  • Podcast management
  • Episode data retrieval
  • Show information
• Webhook Status: Limited native webhook support
• Best Approach: Use REST API with polling for updates
• Documentation: https://github.com/buzzsprout/buzzsprout-api
• Best For: Podcast hosting and distribution

---

6. Podbean

Webhook Support: ⚠️ NOT DOCUMENTED

• API Available: Yes - Podbean API
• Capabilities:
  • Podcast hosting and monetization integration
  • Episode management
• Webhook Status: Limited documentation available
• Documentation: https://developers.podbean.com/podbean-api-docs/
• Best For: Multi-platform distribution and monetization
• Note: May require direct developer contact for webhook capabilities

---

7. Anchor/Spotify for Creators

Webhook Support: ❌ NO

• API Available: Limited
• Capabilities:
  • Basic podcast creation and distribution
  • Monetization options
• Limitations:
  • Minimal API exposure
  • No webhooks available
  • Free tier with revenue sharing
• Best For: Beginner podcasters and Spotify integration

---

SPECIALIZED/EMERGING PLATFORMS

8. Supporting Cast

Webhook Support: ✅ YES

• Capabilities:
  • Developer-friendly webhook system
  • Event-based notifications
• Setup: Via Developers > Webhooks in admin panel
• Documentation: https://developers.supportingcast.fm/webhooks
• Best For: Technical integrations with granular control

---

9. Listen Notes/Taddy API (Third-Party Aggregator)

Webhook Support: ✅ YES

• Capabilities:
  • Podcast index with webhook notifications
  • Real-time episode updates
  • Podcast submission management
  • Episode transcripts (Taddy)
• Events:
  • New episode releases
  • Podcast submissions
  • Episode updates
• Pricing: Free tier available, paid plans for webhooks
• Best For: Centralized monitoring across multiple platforms

Webhook Events (Taddy):

• New episode published
• Episode updated
• Podcast metadata changed

---

INTEGRATION ARCHITECTURE RECOMMENDATION

Tiered Approach

Tier 1: Direct Webhooks (Immediate Notifications)

• ✅ Acast
• ✅ Supporting Cast
• ✅ YouTube (via PubSubHubbub)
• ✅ Taddy API (aggregator)

Tier 2: API Polling (Scheduled Updates)

• Spotify Web API
• Apple iTunes API
• Buzzsprout API
• Podbean API

Tier 3: RSS Feed Monitoring

• Fallback for all platforms
• Monitor RSS feeds directly
• Compare against cached state

---

ARCHITECTURE PROPOSAL

Core Integration Pattern

┌─────────────────────────────────────────────────────┐
│          Podcast Distribution Sync System             │
└─────────────────────────────────────────────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
  ┌──────────┐   ┌──────────┐   ┌──────────┐
  │ Webhooks │   │ API Poll │   │   RSS    │
  │ (Real)   │   │(Scheduled)  │   Feeds  │
  └──────────┘   └──────────┘   └──────────┘
        │               │               │
        │       Direct: Acast           │
        │       YouTube PubSub          │
        │       Taddy Webhooks          │
        │                               │
        │       Polling: Spotify        │
        │       Polling: Apple          │
        │       Polling: Buzzsprout     │
        │                               │
        └───────────────┬───────────────┘
                        ▼
            ┌─────────────────────────┐
            │  Unified Event Queue    │
            │  (Message Broker)       │
            └─────────────────────────┘
                        │
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │  Plan   │   │  Church │   │ External│
   │ DB      │   │  Systems│   │ Services│
   └─────────┘   └─────────┘   └─────────┘

---

IMPLEMENTATION ROADMAP

Phase 1: MVP (Webhooks Only)

• Acast webhook implementation
• YouTube PubSubHubbub setup
• Basic event normalization
• Database event logging

Phase 2: Enhanced (Add Polling)

• Spotify API polling (hourly)
• Apple iTunes polling (daily)
• Deduplicate events across sources
• Implement retry logic

Phase 3: Advanced (Full Integration)

• RSS feed fallback monitoring
• Listener analytics aggregation
• Cross-platform performance metrics
• Listener migration tracking

Phase 4: Intelligence (Analytics)

• Platform preference analysis
• Listener distribution insights
• Growth tracking per platform
• Performance optimization recommendations

---

KEY CONSIDERATIONS

Authentication Requirements

• Acast: API key (user-level)
• YouTube: OAuth 2.0
• Spotify: OAuth 2.0 + Client credentials
• Apple: Public (no auth)
• Buzzsprout: API key
• Podbean: API credentials

Rate Limits & Quotas

• Acast: 60 req/min
• Spotify: Varies (strict for public apps)
• YouTube: Standard API quotas apply
• Taddy: Depends on plan

Data Privacy

• Store only event metadata (not full audio)
• Comply with podcast host TOS
• Cache responsibly to avoid re-polling
• Implement data retention policies

Error Handling

• Implement webhook signature verification
• Retry logic with exponential backoff
• Dead-letter queue for failed events
• Health monitoring dashboard

---

RECOMMENDED THIRD-PARTY ADDITIONS

1. Podtrac / Chartable

• Analytics tracking
• Listener insights
• Could tie into webhook events

2. Transistor

• Emerging hosting platform
• REST API available
• Worth monitoring for webhook additions

3. Libsyn

• Enterprise hosting
• Historical data availability
• API polling capabilities

---

DELIVERABLES CHECKLIST

• Select primary webhook platforms (Acast, YouTube minimum)
• Design event normalization schema
• Create message queue architecture
• Implement authentication system for each platform
• Build webhook receiver/handler service
• Create event storage schema
• Implement polling scheduler
• Set up monitoring/alerting
• Create integration test suite
• Document API specification

---

NEXT STEPS

1. Validate Use Cases: Confirm which events matter most for your system
2. Prioritize Platforms: Rank by user base in your target audience
3. Proof of Concept: Start with Acast + YouTube webhooks
4. Database Schema: Design event storage structure
5. Queue System: Choose a message broker (RabbitMQ, Redis, etc.)

[bcordis]

With this support, I would love to have hooks into each one, as supported, so users can update the podcast service sections and have the service information updated.

With the new support for Video Podcasting, we need to work it into the system to support that.

Not sure if it can be supported in the podcast system or, more directly, in the media creation system so that we can work chapter markers into the system. I know you can do that within the media's description.

To that point, there could be an isort option that allows users to link predefined chapters in the media to the Study Text.

[bcordis]

Will need a way to sync down from the provider if they already have a podcast there. and then link it to the podcast generation system.

[bcordis]

Some of the top podcast platforms only allow form submissions, so we need a way to list them as options and provide links/as directions for submitting your podcast to them.

[bcordis]

Closing this out — the original "list of podcast services with fill-in data" idea at the top of this discussion shipped in Proclaim 10.x, just in a much simpler shape than the architecture this thread eventually grew into. Posting a final summary so future readers know what was kept and what was set aside.

What shipped

• Multi-platform podcast links subform on the podcast edit form — admin enters their Apple Podcasts / Spotify / Google Podcasts / Amazon Music / etc. URLs once, the frontend displays them as platform-branded buttons. Stored in a JSON platform_links column on #__bsms_podcast.
• Podcast Index API lookup integration for podcast discovery and metadata enrichment.
• Configurable iTunes / RSS feed settings — most of what the discussion called "Apple iTunes API" usefulness, since iTunes is read-only anyway and the practical need was "make our RSS feed clean and configurable", which is now done.

What was set aside (and why)

The discussion eventually expanded into a webhook + polling + event-queue + analytics architecture across nine platforms. Concretely not shipping:

• Webhook receivers for Acast, YouTube PubSubHubbub, Supporting Cast, Taddy.
• API polling for Spotify, Apple iTunes, Buzzsprout, Podbean.
• RSS feed fallback monitoring with state-diff detection.
• Unified event queue / message broker (RabbitMQ / Redis pattern).
• Listener analytics aggregation across platforms.

That stack is reasonable for a SaaS or a dedicated podcast-ops platform; it's not the right shape for a Joomla CMS extension. Two reasons:

1. Audience reality. Churches running Proclaim don't typically operate HTTPS callback endpoints with retry queues and dead-letter handling. Asking them to does more harm than the analytics would help.
2. The platforms still don't cooperate five years later. Spotify still has no webhook system. Apple Podcasts is still read-only. The market signal hasn't moved in the direction this proposal assumed.

If push-style notifications become broadly available across the major platforms in the future, this can be reopened with a fresh scope — but as drafted, it would have been a multi-month infrastructure build for benefit that mostly accrues to large publishers, not the church audience Proclaim serves.

Closing as resolved (shipped in different form). The platform-links surface is in 10.x; anything more ambitious can start fresh as a new discussion when the platform landscape changes.