Meta Developers

App to App Travel is a platform travel feature that enables users to travel seamlessly from one app’s destination to another destination in a receiving app. You can use App to App Travel in partnership with another Meta Quest app to send and receive users between destinations within those apps.

Prerequisites for App to App Travel

To enable App to App Travel, you will need:

Destinations created and enabled within the receiving app
The destination_api_name of the partner app to receive users when engaging App to App Travel.
- The receiving developer will need to share the destination_api_name, found on the Developer Dashboard under Engagement > Destinations for their app by inputting the desired destination ID. It is important to communicate with the developers of the receiving app to receive the destination_api_name.
- Many destinations require a deeplink_message sent as part of the launch as well, it is important to communicate with the developers of the receiving app to understand what they expect in the deeplink_message.

Implement App to App Travel

With the above prerequisite information, the sending and receiving apps are now ready for App to App Travel. The receiving app will use destination_api_name, deeplink_message, lobby_session_id, and match_session_id to enable users to be grouped together in a specific destination in the receiving app.

Note: Some apps may be using the legacy Rooms system, which is why the room_id is included. Rooms is scheduled to be deprecated in March 2023, for more information check the Deprecating Oculus Rooms API in March 2023 blog post.

Note: The App to App Travel API does not work in PC/Link mode.

App to App Travel API

ApplicationOptions has been updated and now allows you to pass more information to the receiving app when engaging in App to App Travel. Here is the updated struct:

ApplicationOptions
  deeplink_message:
    type: string
    comment: |
      A message to be passed to a launched app.
  destination_api_name:
    type: string
    comment: |
        If provided, the intended destination to be passed to the launched app
  lobby_session_id:
    type: string
    comment: |
        If provided, the intended lobby where the launched app should take the user. All users with the same lobby_session_id should end up grouped together in the launched app.
  match_session_id:
    type: string
    comment: |
        If provided, the intended instance of the destination that a user should be launched into.
  room_id:
    type: id
    comment: |
        [Deprecated]If provided, the intended room where the launched app should take the user (all users heading to the same place should have the same value). A room_id of 0 is INVALID.

The following is an example using the updated ApplicationOptions:

var appId = 123454321;
var options = new ApplicationOptions();
options.SetDeeplinkMessage("a_message");
options.SetDestinationApiName("example_destination");
options.SetLobbySessionId("1234");
options.SetMatchSessionId("5678");
options.SetRoomId(1474275639758625);
Oculus.Platform.Application.LaunchOtherApp(appId, options);

Receiving an App to App Travel Request

It is recommended that you work with the sending app to ensure that all of the fields are correctly configured.

You can check if your app is being launched using App to App Travel by using the LaunchDetails. An example of checking for App to App Travel launching your app is as follows:

Check the LaunchDetails for your app.
1. Here is an example of what LaunchDetails contains.
Check if the LaunchType is set to DEEPLINK.
Read the LaunchSource.
1. If your app was launched using the updated LaunchOtherApp API you will see LaunchSource set to “OTHER_APP:XXXX” where XXXX is the AppId of the app which is sending this request.

Did you find this page helpful?