Skip to main content
An experience is something your app publishes onto a creator’s Fanvue profile for fans to open: a game, a quiz, a live stream, a video, anything your fan surface can render. The creator chooses who can open it and whether it costs anything, and Fanvue handles the listing, the checkout and the launch. Start here before you build a fan surface or publish anything. You need an on-platform app with a fan experience URL, set in Embed settings or as access.fanExperienceUrl in your manifest. Once it’s in place, Build the fan surface and Publish experiences take you the rest of the way.

​
Access modes

The access mode decides who can open an experience and what, if anything, they pay. The creator picks it in the confirmation dialog, where the App subscription option is PAID with priceRecurring: true. Every charge is between the fan and the creator. Payments inside experiences covers paid access, priced actions and who gets paid.

​
Delivery modes

Both modes append ?token= to the URL they open. The SDK’s mintPublishRequestToken produces EMBEDDED only; EXTERNAL is available through direct publish on the API.

​
Experience types

experienceType is one of LIVE_STREAM, LIVE_AUDIO, VIDEO, AUDIO, GAME, CHALLENGE, QUIZ, EVENT or OTHER, and defaults to OTHER. The type is presentation only. Chat cards show it as a category tag, and OTHER shows no tag. The creator can change the type you propose in the confirmation dialog, and the token exchange returns the type they confirmed. Read it from the exchange rather than assuming your proposal survived.

​
How an experience is identified

An experience is one row per app, creator and externalExperienceId. Publishing the same externalExperienceId again for the same creator updates that row in place and keeps its position on the profile.

​
What fans see

Fans reach an experience from four places. Signed-out visitors are sent to sign-in first.
  • Profile tab. The creator’s profile shows an Experiences tab listing published, non-hidden experiences. The tab is hidden when there are none.
  • Detail page at /experiences/detail/{uuid}: cover, description and the call to action. ?intent=purchase opens the checkout step directly, and ?source=chat_embed marks a visit from a chat card.
  • Surface page at /experiences/{uuid}, where Fanvue renders your fan surface.
  • Dialog over a chat or a profile at ?experience={uuid}&exp_source=chat_embed|profile|link, when your fan surface uses dialog presentation.
The call to action depends on who is looking: EXTERNAL experiences show an open in button instead of rendering a surface. A chat message containing a Fanvue link to /experiences/{uuid} or /experiences/detail/{uuid} renders a card above the message bubble, and a profile link to /{handle} renders a card too. A message that is only a link renders the card in place of the bubble. Each message renders at most 3 cards per kind, and cards render for viewers whose account has chat link cards enabled. A card shows the cover from imageUrl, the creator’s avatar and handle, badges, the category tag from experienceType, and the call to action. The description appears only on the detail page, and an unpublished experience renders as an unavailable card. To get a good card, supply a public https cover, a short title, a type other than OTHER and a description. HIDDEN experiences are reachable only through the detail link. The SDK builds share links with experienceDetailShareUrl and experienceShareUrl.

​
Limits

​
Lifecycle and availability

A published experience survives an uninstall, an archive, a suspension and a withdrawn submission. What changes is whether fans can see it. The fan listing hides an experience while the app is unavailable, and an app is available only when all four conditions hold:
  • it has a current submission
  • it is not suspended
  • it is not archived
  • the creator still has it installed
Launch, token exchange and purchase re-check the same conditions and answer not found when any of them fails.