Skip to main content

Testing with sandbox users

Test uploaded builds with sandbox users​

Sandbox users are real, logged-in Jest accounts created from the Developer Console.

Use them to test an uploaded build of your app inside the live Jest.com platform as a logged-in player.

Sandbox users only see your team's apps (apps your developer account can access).

Create a sandbox user​

  1. Open the Developer Console.
  2. In the left sidebar navigation, select Sandbox Users.
  3. Select Create Sandbox User.

Log in as a sandbox user​

  1. In the Developer Console, go to Sandbox Users.
  2. Select Generate Login Link for the user you want.
  3. Open the link in a browser.

A small "Sandbox user" overlay at the top of the page indicates you are in sandbox mode.

What you can do with sandbox users​

Sandbox users are best suited for testing platform-backed features against an uploaded version of your app.

From the Developer Console, you can also inspect and manage a sandbox user while you test, for example:

  • Inspect scheduled notifications and see what arrives in the sandbox user's inbox
  • Test purchase and subscription flows without real charges while seeing configured prices
  • Reset player state across the sandbox user's apps to re-test first-time or onboarding flows

Good for​

  • End-to-end testing of SDK features on the real platform with an uploaded build
  • Testing flows that require a logged-in user (registration gates, user identity, persistent state)
  • Verifying that platform features behave correctly (notifications, payments, redirects)
  • Debugging issues that only show up in the real hosted environment (embedding, platform UI, mobile viewport behaviors)

Not good for​

  • Iterating quickly on local UI/logic (use local mocks)
  • Testing local code inside Jest.com without uploading a new build (use the hosted emulator)

For step-by-step UI instructions in the Developer Console, see Sandbox users.

Prices during sandbox testing​

Product catalogs and the platform purchase dialog show configured prices. The dialog explains that no charge will be made. Completed sandbox product purchases cost zero credits, and their PurchaseData.price is 0. See Payments.

Subscriptions also retain the configured plan price in SubscriptionData.price, even though sandbox subscription checkout uses a zero price. A nonzero displayed or returned plan price does not mean the sandbox user was charged. Use the sandbox flag described below to identify test activity.

Recognize sandbox activity in your backend​

Purchases and subscriptions belonging to a sandbox user carry sandbox: true, both in the SDK payload and inside the signed token your backend verifies:

The Developer Console simulator sets the same flag on the purchases and subscriptions it fabricates, so the check covers both testing paths. The field is absent for real users, so check for sandbox === true. Keep granting items and entitlements when it is set — that is what makes the sandbox worth testing against — but exclude those records from anything that counts real money, such as revenue reporting or spend-based rewards.

Test referrals​

Referrals need two users — a referrer and an invitee — so the test loop uses two sandbox users.

  1. Create two sandbox users, A (the referrer) and B (the invitee). Each developer can have up to 3.
  2. Log in as A and mint a referral link:
    • Generate A's login link and open it in one browser.
    • Enter your app and call the referral share method exposed by your SDK (HTML5, Unity3D, Godot).
    • Copy the shared link from the system share dialog.
  3. Log in as B in a separate browser or incognito window so the two sessions don't collide. You'll land on the Jest.com home page.
  4. Paste A's referral link into B's address bar. The platform redirects B into A's app with the referral attached, and B's user record is attributed to A's link.
  5. Confirm the conversion by calling listReferrals from A's user (the entry shows up under the reference you used) or by opening A's inbox in the Developer Console — A receives a referral_conversion notification once B is attributed.

Re-running the loop with the same sandbox users​

Referral attribution is decided once, when a user first enters your app — an existing user who later opens a referral link is not re-attributed. To run the loop again with the same sandbox users:

  1. In the Developer Console, open Sandbox Users and select Reset Player State for sandbox B. This resets B's player state across all apps, including the app under test. See Reset player state for the scope of the reset.
  2. Repeat steps 3–5. The next time B enters A's referral link, a brand-new Player record is created with the attribution attached, and A receives another conversion notification.

Calling shareReferralLink from A's user a second time with the same reference updates the existing link (it's an upsert), so B's repeat entry rolls into the same campaign.

Notes​

  • The platform's only built-in reward for a conversion is the notification delivered to A's inbox. Anything else (currency, items, feature unlocks) is your app's responsibility — verify the referralsSigned JWS server-side before granting it. See the HTML5 SDK Referrals guide for the verification recipe.