Is This a Forum Post or a Support Ticket?

With so many options for support, it can be hard to tell where to ask certain questions. To help you navigate our support structure, we’ve put together this best practices guide. 

As a general rule, we recommend posting to the Developer Forum when the answer to your question could help someone else in the same situation and filing a ticket with Developer Support when the answer is specific to you, your org, or your account. This means that questions around feature implementation, such as how to use SDKs, would be a great fit for the forum, while being locked out of your developer account would be better suited to a Support ticket. 

Some examples of forum post topics include:

• Non-technical questions e.g., I’m a Unity developer looking for advice on how to get started developing for Meta Quest or How have other developers approached sound design
• Technical implementation questions e.g., I’m having an issue integrating Passthrough API into my Unity project
• Discussions comparing different tech stack options e.g., Will performance optimization for my specific app be easier in Unity or Unreal Engine

The Developer Support team is here to help you with more individual requests like:

• Payout/Monetization issues e.g., I didn’t receive a payout or I see an error when onboarding/editing my payout details
• Integrity e.g., data use checkup, Data Protection Assessment, age ratings, enforcement appeals
• Bug escalations e.g., I have already reported a bug but require more immediate support or the bug is severe
• Store submissions e.g., Store submission status and VRCs
• Questions around the Meta Store or App Submission process e.g., I’m having trouble finding my app on the Meta Store 
• Administrative Changes e.g., delete an app, delete an org, transfer apps, key management
• Technical Support e.g., bug report and product feedback (if it cannot be submitted in MQDH), dev mode issues, and documentation edit requests

Our support team has put together characteristics that are helpful in triaging bug reports and ensuring reproducibility. When submitting a bug or report, we ask that you keep these characteristics in mind.

Bug reports that are not reproducible are substantially harder if not impossible to debug for our engineering teams. The more details a report has, the easier a bug will be to reproduce. Please remember to report using the in-tool bug and feedback reporting flows e.g., MQDH and in-product integrity tools before reaching out through the Support Center.

Characteristics of a Helpful and Complete Bug Report

1. Provide Your Username: This is especially helpful if you're reaching out through email.
2. Date & Time of ABXY: If your bug is a long-term issue or recurring issue, include the most recent date and time of the issue recurring. As well as any details about the amount of times it has occurred.
• Example: “The bug first occurred on 1/10/25 after I’d updated to the new OS. The bug stopped showing up after a few days, then returned after I updated to the new version of the OS on 2/10/25.”
3. World Name: Whether your world is published or not, providing your world name is integral to reproducing the issue and debugging potential causes.
4. Reproduction Steps: Be as clear and prescriptive about the steps needed to reproduce the bug you’ve experienced, particularly if it is related to a scripting error.
• Example:
• Helpful steps: Press switch to VR in the desktop editor in a world that has a screen overlay. 
• Unhelpful steps: Switch to VR while editing the world. 
5. Preconditions: What was happening before you experienced this bug?
• Example:
• Did you make any changes to their world between the last time you accessed it and the time of the bug occurring? 
• Did you update your MQDH/HzOS/SDK version? 
• Did you have a huge growth of followers?
• Are there any other extenuating circumstances we should know of? 
6. Descriptive Observed and Expected Behavior: Much like Repro Steps, these should be specific and clear. 
• Example:
• Unhelpful steps: 
• Expected behavior: Items work. 
• Observed behavior: Items don’t work. 
• Helpful steps: 
• Expected behavior: When the player picks up an item in game, the item is added to their inventory. 
• Observed behavior: When the player picks up an item, the item disappears from the world, but isn’t listed in their inventory. 
7. Build Blocking: How detrimental is this to your development flow?
• Is the issue fully blocking you from moving forward? 
• Is it intrusive but you are still able to build?
• Is the bug slowing you down but you are able to find a workaround?