Migrating to Network Enabled Zero Permissions

1. Go to the App Dashboard and select your app.
2. Navigate to Use Cases > Customize “Launch a game on Facebook” > Network Connection Settings > Connection Experience Settings.
   • If Use Cases is not in the sidebar, look for Network Connection Settings under Instant Games.
3. Select Zero Permissions and confirm.

Note: After you select Zero Permissions, all Platform Test Users default to the Zero Permissions model. If you use test users to validate your current production build, do that before you change this setting.

1. Navigate to Use Cases > Customize “Launch a game on Facebook” > Network Connection Settings > User Data Deletion.
2. Delete the following from your systems, including backups, logs, and analytics warehouses:
   • Player names
   • Player profile pictures
   • Friend names
   • Friend profile pictures
3. Keep player IDs and gameplay data. Scores, progress, inventory, and purchase history may all be retained.
4. Select the confirmation checkbox and save.

1. Navigate to App Review > Permissions and Features.
   • Direct link: https://developers.facebook.com/apps/YOUR_APP_ID/app-review/permissions/
2. Find Instant Games Zero Permission Access.
3. Select Request Advanced Access.

1. Navigate to Use Cases > Customize “Launch a game on Facebook” > Permissions and features.
   • Direct link: https://developers.facebook.com/apps/YOUR_APP_ID/use_cases/customize/?use_case_enum=INSTANT_GAMES&business_id=YOUR_BUSINESS_ID&selected_tab=permissions&product_route=use_cases
2. Find Instant Games Zero Permission Access.
3. Select Actions > Increase access.

<!-- Before -->
<script src="https://connect.facebook.net/en_US/fbinstant.7.1.js"></script>

<!-- After -->
<script src="https://connect.facebook.net/en_US/fbinstant.8.0.js"></script>

1. Go to the App Dashboard and select your app.
2. Navigate to Instant Games > Content Security Policy.
3. Add each domain without the https:// prefix or a trailing slash, and select only the directives that domain needs.

Note: Overlay views cannot load images from an external CDN, even one on your CSP allowlist. Overlay images must come from your game bundle, a player photo template expression, or a base64 data URL passed in as initial data.

• The player’s own avatar and display name in the HUD or profile panel
• Friend lists and friend pickers
• Leaderboards, both friend and global
• Match, lobby, and turn-order UI
• Gift, challenge, and invite flows
• Chat and activity feeds
• Any name or photo baked into a share image

<View className="card">
  <Image src="{{FBInstant.player.photo}}" className="avatar" width="48" />
  <View>
    <Text content="{{FBInstant.player.name}}" className="name" />
    <Text content="Score: {{score}}" className="score" />
  </View>
</View>

.card {
  display: flex;
  align-items: center;
  gap: 12px;
}

.avatar {
  width: 48px;
  height: 48px;
  border-radius: 50%;
}

var container = document.getElementById('playerCard');

var overlay = await FBInstant.overlayViews.createOverlayViewAsync(
  'overlays/profile_card.xml',
  container,
  'width: 100%; height: 64px; border: none;',
  'overlays/styles.css',
  { score: 1500 }
);

await overlay.showAsync();

<View className="friendRow" onTapEvent="challenge_{{friend.id}}">
  <Image src="{{friend.photo}}" className="avatar" />
  <Text content="{{friend.name}}" className="name" />
</View>

FBInstant.overlayViews.setCustomEventHandler(function(eventStr, overlayID) {
  if (eventStr.startsWith('challenge_')) {
    startChallenge(eventStr.split('_')[1]);
  }
});

await overlay.updateAsync({ score: 2000 });
await overlay.showAsync();

• updateAsync() re-renders the whole overlay. There is no incremental patching, and every image is re-fetched. Throttle updates to meaningful state changes rather than calling them each frame.
• dismissAsync() only hides the overlay. The iframe stays in the DOM with its state intact, which makes it cheap to show again.
• destroyAsync() frees the overlay. Use it to remove the iframe and release resources for overlays you will not show again. Long sessions that create overlays without destroying them will accumulate memory.
• Reuse beats recreate. For variable-length lists such as per-player name tags, pre-create a pool at startup and recycle it.

var players = await FBInstant.player.getConnectedPlayersAsync();
var ids = players.map(function(p) { return { playerID: p.getID() }; });

var overlay = await FBInstant.overlayViews.createOverlayViewAsync(
  'overlays/friend_list.xml', container, null, 'overlays/styles.css', { players: ids }
);
await overlay.showAsync();

<View>
  <For source="{{players}}" itemName="i">
    <View className="friendRow" onTapEvent="select_{{i.playerID}}">
      <Image src="{{FBInstant.players[{{i.playerID}}].photo}}" className="avatar" />
      <Text content="{{FBInstant.players[{{i.playerID}}].name}}" className="name" />
    </View>
  </For>
</View>

1. Navigate to Use Cases > Customize “Launch a game on Facebook” > Web Hosting.
2. Toggle Network Enabled Zero Permissions Settings at the top of the page.
3. Upload your v8.0 bundle as a ZIP file, with index.html and fbapp-config.json at the top level of the archive rather than inside a folder.
4. Wait for the platform to finish scanning the bundle.
5. Mark the bundle you want to serve in NEZP with the shield icon.

• Overlay views. Check every surface from your Step 7 inventory, on more than one account, with both real profile pictures and gaming avatars.
• Removed APIs. Confirm nothing renders a blank name or a broken image, which is how a leftover getName() or getPhoto() call usually shows up.
• Network requests. Watch the browser console for CSP violations, and confirm your backend, analytics, and ad calls all succeed.
• Player identity. Verify that getID() returns the same ID it did before migration and that saved progress loads.
• Cross-platform. Test on Facebook web, iOS, and Android. Overlay sizing and tap targets are the most common source of platform-specific issues.

• Confirm you are actually in NEZP. In Chrome DevTools, check that index.html is served from shield-apps-{your-app-id}. Without the shield prefix, you are running the standard environment.
• Give internal testers the Developer role. The NEZP toggle is honored for people with the Admin or Developer role on the app. Someone assigned only the Tester role may still be served the standard environment.
• Disable the cache while iterating. Bundle JavaScript is cached aggressively. Turn on Disable cache in the DevTools Network panel, or hard-refresh, so you are testing the bundle you just uploaded.
• Turn on debug mode. The in-game debugging tool includes an overlay view inspector that shows each overlay’s state and resolved data.

1. Go to Instant Games > Review > App Review for Instant Games.
2. Add your game to the submission.
3. Confirm that Instant Games Zero Permission Access with advanced access from Step 3 is included in the same submission.
4. Submit.

• Zero Permissions selected in Connection Experience Settings (Step 1)
• User data deletion confirmed (Step 2)
• Instant Games Zero Permission Access approved with advanced access (Step 3)
• A NEZP bundle uploaded and marked with the shield icon (Step 11)
• App review complete (Step 13)

1. In the Zero Permissions Users Rollout card, select a small starting value from Rollout percentage and select Confirm.
2. Monitor retention, session length, crash rate, purchase conversion, and ad revenue against your pre-migration baseline for long enough to see a real signal.
3. Increase the percentage in stages until you reach 100%.

• Select Zero Permissions in Connection Experience Settings
• Delete stored names and photos, and confirm user data deletion
• Request advanced access to Instant Games Zero Permission Access

• Audit every call to getName(), getPhoto(), and FBInstant.globalLeaderboards.*
• Inventory every screen that displays a player name or photo
• List every external domain your game contacts
• Record a pre-migration baseline for retention, session length, and revenue

• Upgrade the SDK script tag to fbinstant.8.0.js
• Remove unsupported API calls and permission-checking logic
• Add your domains to the Content Security Policy configuration
• Implement an overlay view for each surface in your inventory
• Reuse or destroy overlays rather than leaking them

• Upload the v8.0 bundle and mark it with the shield icon
• Confirm the game is served from shield-apps-{app-id}
• Test every overlay surface on web, iOS, and Android
• Confirm no CSP violations in the console
• Confirm player IDs and saved progress are unchanged
• Confirm purchases and ads still work

• Submit for app review with the access request included
• Resolve all Launch Status health-check items
• Roll out incrementally, monitoring metrics at each stage
• Reach 100% and verify the shield bundle is serving production

• Overlay View Components — Full XML component reference.
• Example Game Use Cases — Worked examples for friend lists, leaderboards, and profiles.
• API Reference — Complete SDK v8.0 reference for Zero Permissions.
• Testing — Facebook player and local testing.
• FAQ — Common questions about data deletion, permissions, and rollout.
• Get Support — Support channels if you get stuck.