Skip to main content
Fanvue has no sandbox. Every call hits the live API and every charge is real money, so testing means running your unapproved app against accounts you control. By the end of this page you’ll have a test creator account, a draft install of your app that only you can see, and test webhooks arriving at your endpoint. You need an app in the Developer Area, and the Debug tab needs it to be off-platform or on-platform. When testing is done, Submit your app for review covers the submission.

​
Accounts to test with

Test accounts keep development data out of your real creator profile. Use a dedicated test creator account as the user of your app, never the creator login you publish with.
  1. Keep the app on your main account. The app, its Client ID and its Client Secret stay in your main account’s Developer Area.
  2. Register a separate Fanvue account as a test creator. Use a different email address. This account authorises your app and holds the test data: messages, posts and subscriber activity.
  3. Add more accounts for more roles. A second test account can act as a fan or subscriber, or be invited as a team member to exercise agency behaviour.
The account you hand to reviewers must be one you can share. The submit dialog asks for test credentials for an account that:
  • is active
  • has full admin privileges
  • doesn’t require any payment
Create that account for review alone and keep your own login out of it. Keep separate apps for development and production, each with its own Client ID, redirect URIs and app domain, so production credentials never sit in your development environment.

​
Install and open your draft app

On accounts with unpublished access enabled, the owner of an app with no approved submission sees Install app on App details, then Open app and Uninstall app once it’s installed. The launched app shows a Delisted pill, whose tooltip tells you to submit the app for moderation to see it on the App Store. The owner’s install is a draft install. It stays out of install counts and App Store analytics, becomes a counted install when the submission is approved, and survives a rejection. Nobody other than the owner can reach the draft, because it appears in no listing, search or recommendation.

​
Debug tab

Off-platform and on-platform apps get a Debug tab on App details. It frames the draft of an app that has never been approved, or the pending submission of a live app. A notice states that the draft is visible only to you, stays out of the App Store, search and recommendations, and isn’t counted as an install. Only on-platform apps show framed content, since an off-platform app has no surface to frame. The preview host is a *.fanvue.com origin, so your Content Security Policy must allow it as a frame ancestor; see Hosting requirements.

​
Test webhook delivery

Test on the Events tab delivers a synthetic event to your webhook endpoint. For it to work, you, as the owner, must have authorised your own app with the scope the event requires: To fix either, authorise your app from your own account, grant the missing scope and retry. POST /webhooks/test does the same from the API, limited to 30 requests per minute. It rejects the nine deprecated flat events with a 400 validation body, and returns 404 when no active subscription exists for the topic. Identifiers inside data are prefixed TEST-. purchaser.email and transaction_id are populated in test payloads but are null on production creator.payment.* deliveries. See Test a destination.

​
Test a fan experience

Fan experiences on an unapproved app are reachable by the owner alone. Install your draft app, open it and publish an experience from it, then open the experience as the owner. Other fans can’t open it until the app is approved. See Test before approval.

​
What you can test deterministically

Verify event handling with test and free events first. Only the final money assertions need a real charge.