> ## Documentation Index > Fetch the complete documentation index at: https://api.fanvue.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Test your app before you submit > Install, open and debug an unapproved Fanvue app, send test webhooks and set up a test creator account before you submit it for review. 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](/docs/app-store/publishing-your-app) 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](/docs/app-store/sdk/embedded#hosting). ## 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: | Problem | Error | | - | - | | You haven't authorised the app at all | `WEBHOOK_TEST_AUTH_REQUIRED` | | Your authorisation lacks the event's scope | `WEBHOOK_TEST_SCOPES_REQUIRED` | 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](/docs/webhooks/subscribing#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](/docs/app-store/experiences/publish#test-before-approval). ## What you can test deterministically | Scenario | How | | - | - | | OAuth flow, scopes, `401` and `403` | Authorise with the test account; request a scope you have not enabled to produce a real `403` | | Webhook delivery and signatures | **Test** on the Events tab, or trigger free events from the test account (follow, message, post); no money required | | Paid flows | A real card at the minimum price. Refund through support afterwards | | Payment declines | Not deterministically triggerable; there are no test cards. Build handling from [Failure reasons](/docs/checkout/payments#failure-reasons) | | Rate limiting | Loop past 200 requests in 60 seconds on the test account and assert on the `429` headers; see [Rate limits](/docs/authentication/rate-limits) | | Agency behaviour | A second test account invited as a team member | Verify event handling with test and free events first. Only the final money assertions need a real charge. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.