Skip to main content
All CollectionsAdvanced ToolsAcast+ Access
Acast+ Access Customer Onboarding Guide
Acast+ Access Customer Onboarding Guide
Updated over 4 months ago

Acast+ Access is our B2B private listening service. With Acast+ Access you keep full control of the relationship with your audience, but with the ability to manage access to premium podcast content from within our platform.

Key Terms & Concepts

The following concepts are useful for understanding how Acast+ Access works and how to integrate it with your systems.

Term

Explanation

ShowId

A unique identifier for a Show, created by Acast at the time the show is created in our CMS.

Token

A special key created to make a Private RSS feed for a Subscriber. This is a unique connection between a Subscriber and a Show, created using the Access API.

Private (RSS) Feed

This is a unique version of a Show's RSS feed, connected to a show. It is formed by appending the Token to the show feed.

Access API

This API allows you to manage Feeds for your Subscribers by creating, disabling or reactivating Tokens.

UserId

A unique identifier for one of your subscribers. We can't connect it to a person, but it is useful if there is a 1:1 relationship between ID and Subscriber, e.g. for canceling all their tokens when they unsubscribe.

How private RSS feeds work

RSS is the basis for modern podcasting and is what allows podcasts to be available for listening in whichever app you choose. At Acast we use individual, private RSS feeds for each listener to enable private listening. This gives Subscribers the flexibility to listen in whichever app they choose, while allowing us to ensure that your premium content is only available to them. This is also the mechanism for removing access to content if the subscription ends.

Integrating with Acast+ Access

The key steps to integrating with Access are:

  • Making feeds for your subscribers

  • Sharing the feeds with your subscribers (e.g. using the Acast Subscribe Page links)

  • Canceling subscriber tokens when subscriptions end.

The subscription lifetime for a particular listener looks something like this:

Creating tokens

Each user should be provided with a unique feed URL for any shows that they subscribe to. We would recommend using the Acast subscribe page or building something similar. To create the token and feed url, make an HTTP POST to https://access.acast.com/api/v1/tokens (swagger docs), or create multiple with an HTTP POST to https://access.acast.com/api/v1/tokens/batch (swagger docs).

With either of the above endpoints:

  • showId is the Acast show ID that you can see in the cms or in the feed at /rss/channel/acast:showId (XPath)

  • userId is a unique identifier for the user. It should not contain any personally identifiable information (PII), and should map 1:1 to the user in your system.

The request body is these two parameters as JSON

{ "showId": "<showId>", "userId": "<userId>" }

Disabling tokens

When a user's subscription lapses or is canceled, their tokens can be deactivated with a HTTP PUT to https://access.acast.com/api/v1/users/{userId}/disable (swagger docs). This will prevent them from accessing subscriber benefits, while keeping their feed url unchanged. If they resubscribe they can be reactivated without needing to update their podcast app.

Enabling tokens

If a user resubscribes after their subscription has ended/lapsed, their tokens can be reactivated with a HTTP PUT to https://access.acast.com/api/v1/users/{userId}/enable (swagger docs) and they will regain any subscriber benefits.

Integrating with the Acast CMS

Integrating with the Acast CMS is outside the scope for this document. More information can be found in the Acast CMS API documentation, or can be provided on request.

Using the CMS api to get links to podcast audio is not recommended. These should be taken from the appropriate RSS feed. Either the public feed or the individual feed for the listener. This allows us to make sure that the audio can be tailored to the user's needs.

Serving audio to customers

If you want to serve audio to your customers within an app journey or somewhere else on your site, the audio URL should always be taken from the RSS feed. Using the audio URL returned from the CMS API to serve audio to users is not supported.

Take the audio URL from the public RSS feed for users who are not logged in / subscribed, or from the user's individual private (tokenised) feed if they are. This ensures that we can serve them the correct audio with the appropriate settings, as well as checking token validity for accessing private content.

FAQ

My private feed is configured not to serve ads, but I hear them in testing what's going on?

This can be caused by a few different things:

  1. XML encoded URLs: Double-check there are no xml artifacts in the audio link (e.g &amp; instead of &)

  2. The token is invalid for some reason: At the bottom of the RSS feed content there is a section labeled podaccess:user which should tell you if the token is valid (XPath: /rss/channel/podaccess:auth/podaccess:user)

  3. The feed could be incorrectly configured. Let us know and we can investigate.

Can I use the same feed for everyone

This is not recommended. Access has been designed with the intention that each subscriber receives a unique Private RSS Feed. This allows us to deactivate the feed when their subscription ends. Having a unique per-user feed is also what enables detection of shared feeds.

I have deleted a feed, but it still serves RSS

When a token is deleted we serve the default (public) version of the feed. The intention is to avoid breaking the feed in their podcast player.

Did this answer your question?