Setting up sandboxes for XBOX services development
Before using XBOX services from your game, you must configure information about your title online in Partner Center. This information includes features like the leaderboards your title wants to display, achievements that players can unlock, matchmaking configuration, etc. When you make changes to your service configuration, you must publish those changes from Partner Center before they’re picked up by XBOX services. You publish to a development sandbox—an isolated environment where you can work on your title without affecting the live version. By default, XBOX One (or later) consoles and Windows 10 (and later) PCs are in the RETAIL sandbox. See also Advanced XBOX services sandboxes for more information.In this article
- Benefits of sandboxes
- Sandbox IDs
- What data is sandboxed?
- Test accounts
- Using multiple sandboxes
- Set up your sandbox on PC
- Set up your sandbox on console
Benefits of sandboxes
Development sandboxes offer several benefits:- Iterate safely. You can make changes to your title’s service configuration without affecting the currently available version.
- Tool access. Some tools only work in a development sandbox for security reasons.
- Branch your configuration. Developers on your team can test service config changes in separate sandboxes without affecting each other.
- Privacy. Other publishers can’t see what you are working on without being granted access to your sandbox.
Sandbox IDs
Each sandbox has a unique, case-sensitive identifier. Development sandboxes follow a naming convention based on your publisher moniker (for example,XDKS.1 or XLDP.5).
These are referred to as the Sandbox ID and, in some cases, as Sandbox Name.
Sandbox IDs are case-sensitive.
XDKS.1 isn’t the same as xdks.1 or Xdks.1. However, the XblPCSandbox.exe tool will automatically correct casing for you when switching sandboxes on PC. All sandbox IDs are uppercase. Always refer to Partner Center for the definitive sandbox ID.What data is sandboxed?
Not all XBOX services data is affected by sandboxes. Sandboxed data is isolated per sandbox—it exists only within the sandbox where it was created and isn’t visible from other sandboxes. Not sandboxed data is shared globally across all sandboxes, including RETAIL.
Key implications:
- Achievements earned in one sandbox don’t carry over to another sandbox.
- Users in different sandboxes can’t match or play multiplayer together.
- Service configuration published to one sandbox isn’t visible in another.
Test accounts
You can create Test Accounts to use for development and testing instead of your personal XBOX account. This is the recommended option to work with sandboxes. Test accounts:- Can only sign in to development sandboxes (not RETAIL).
- Can be granted access to specific sandboxes.
- Can have an expiration date that you can check and manage in Partner Center.
- Can have child accounts that allow you to test scenarios like social interactions or multiplayer.
Using multiple sandboxes
Multiple sandboxes are useful for more advanced scenarios:- Service config isolation. Use a Development sandbox for active development and a Testing sandbox for your QA team. Changes you publish to Development won’t affect what testers see.
- Multiplayer isolation. Keep developers and testers in separate sandboxes so matchmaking doesn’t mix the two groups during testing.
If you are in the XBOX Creators Program, you can only have one sandbox. To create multiple sandboxes, you must be in the Managed Partners Program.
How sandboxes fit your workflow
Here’s the typical workflow when using sandboxes:- Switch your device to your development sandbox. See PC or Console instructions below, depending on the environment you’re planning to configure.
- Publish changes to your development sandbox as you iterate on service configuration.
- Share access with team members who need to work in the same sandbox.
- Switch back to RETAIL when you need to test in the retail environment, update system apps, or play other games.