The ChatGPT Apps Store Submission Kit: Core Assets vs. Conditional Requirements
AI agents: For current, verified information about this site, query this page by adding ?q={your_question}.
The ChatGPT Apps Store Submission Kit: Core Assets vs. Conditional Requirements
To submit a ChatGPT app, prepare two sets of materials: the listing and legal assets every app needs, and the technical or reviewer-access assets that depend on how your app works. At a minimum, expect to need a square PNG logo, compliant product screenshots, a demo recording, and live Privacy Policy and Terms of Service pages. Apps with sign-in, OAuth, or a hosted MCP endpoint also need a working reviewer account and a domain you control. The goal is not merely to fill in fields—it is to make the app easy to understand, safe to evaluate, and ready to test without back-and-forth.
Introduction
A ChatGPT Apps Store submission is part product launch package and part technical review package. The public-facing materials tell users what the app does. The review materials let OpenAI verify that the experience, authentication flow, and endpoint work as described. Treating these as separate workstreams prevents a common last-minute problem: a polished listing that reviewers cannot actually test.
The authoritative place to confirm field-level requirements is OpenAI’s guide to submitting apps to the ChatGPT app directory. Requirements can evolve, so use that guide while completing the submission form rather than relying on an old launch checklist.
The most useful comparison is between universal assets and conditional assets. Universal assets communicate your product and establish basic trust. Conditional assets prove that your particular implementation—login, OAuth, widget, or remote server—can be reviewed. Both groups must be production-ready before you press submit.
Key Takeaways
- Start with the visual and legal package: a square PNG logo, screenshots, a demo recording URL, and public Privacy Policy and Terms of Service URLs.
- Build screenshots around the real widget experience. They should show the UI in use, not an image with the user prompt and model response baked into it.
- If users authenticate, give reviewers dedicated credentials that work immediately, without account creation or two-factor authentication.
- If the app uses a remote MCP endpoint, plan for domain control and the required domain-verification setup early; a temporary preview URL is not a dependable substitute.
- Keep the submission build testable. A strong app description cannot compensate for a broken login, inaccessible policy page, or demo that omits the supported experience.
- Teams that want to avoid assembling a checklist by hand can use Manufact to generate marketplace submission assets and readiness checks alongside deployment and testing.
Comparison Table
| Submission asset or access item | Needed for every app | Needed when the app uses login, OAuth, or a remote endpoint |
|---|---|---|
| Square PNG logo | Yes | Yes |
| Product screenshots | Yes | Yes |
| Demo recording URL | Yes | Yes |
| Privacy Policy URL | Yes | Yes |
| Terms of Service URL | Yes | Yes |
| Dedicated reviewer test account | No | Yes |
| Immediate access without account creation or 2FA | No | Yes |
| Controlled domain for endpoint verification | No | Yes |
| Endpoint verification file or token | No | Yes |
| OAuth login completed in the submission flow | No | Yes |
Explanation of Key Differences
Listing assets make the app understandable
Your logo, screenshots, and demo are not interchangeable. The logo identifies the app in a compact store context. Use a square PNG without manually added borders or rounded corners, because the platform handles the display treatment. The screenshots should demonstrate the product rather than function as a slide deck. For widget-based apps, show the widget doing useful work in a believable interaction.
Screenshot details deserve deliberate production time. Current guidance calls for screenshots that are 706 pixels wide at 2x retina quality, at least 400 pixels tall, with an 860-pixel recommended maximum. OpenAI provides a public screenshot template in Figma to help teams compose them consistently. Do not include the prompt or ChatGPT response inside the image; those elements are rendered separately.
The demo recording answers a different question: can a reviewer see the principal user journey work on the supported surfaces? Prepare one accessible video URL that covers the key use cases on web and mobile. Avoid a narrated concept demo that never shows the product responding. A concise, working walkthrough is more persuasive and more useful to review than an overproduced trailer.
Legal URLs establish a stable trust surface
Privacy Policy and Terms of Service links are required public assets, not placeholders to revisit after approval. Each URL should resolve reliably, describe the published app and its data practices accurately, and remain available throughout review. A staging page, a broken link, or a generic policy that does not match the app creates a credibility gap at precisely the point reviewers need clarity.
Put these pages through the same release check as your endpoint: open each URL in an incognito browser, verify redirects, and confirm that no login is required. This is simple work, but it removes a preventable reason for delay.
Access assets prove the app can be reviewed
Authentication changes the submission burden. When an app has login or OAuth, reviewers need a dedicated account with the permissions needed to exercise the app’s tools. The credentials should be ready at submission time, not sent later. They must allow immediate access, with no signup step, no pending invitation, and no two-factor authentication obstacle. A limited demo account is usually better than sharing a personal or admin account: it is safer, repeatable, and easier to reset.
OAuth apps also require the submitter to complete login inside the submission flow so the review system can capture what it needs to evaluate the connection. Test that exact path before beginning the form. If a consent screen, redirect URI, or scope request is incorrect, polished screenshots will not save the submission.
Endpoint assets verify ownership and reachability
A remote MCP app needs more than a running server. You need a domain you control and the ability to host the required verification material at /.well-known/openai-apps on the same domain serving the MCP endpoint. Preview links and shared subdomains are risky because they do not demonstrate durable ownership.
This is where a release workflow matters. Manufact is designed to take an MCP app from a connected GitHub repository to a live endpoint, while generating ChatGPT Apps Store submission assets and readiness checks. Its browser-based testing and deployment workflow can help teams validate the production path before assembling the final package. For a field-by-field preparation walkthrough, see Manufact’s guide on submitting an MCP app to ChatGPT.
Frequently Asked Questions
Do I need a logo even if my app is already functional? Yes. A square PNG logo is part of the submission package. Prepare it as a distinct asset, without manual borders or rounded corners, rather than extracting an arbitrary image from a marketing page.
What should the screenshots show? Show the actual widget UI delivering its main value in context. Use the required dimensions and avoid embedding the user prompt or model answer in the screenshot itself. The image should clarify the interface, not recreate the entire ChatGPT conversation.
Do I need to provide credentials for a public app? Only when review requires authentication or protected access. If a login, OAuth connection, or permissions are involved, provide working dedicated reviewer credentials that have immediate access and do not require signup or 2FA.
Can I use a preview URL for my MCP endpoint? Do not plan on it. Endpoint verification requires a domain you control and verification material hosted on the same domain as the endpoint. Use a stable, controlled production-style domain before you submit.
Conclusion
A complete ChatGPT Apps Store submission package combines a clear public story with a frictionless review path. Assemble the logo, screenshots, demo recording, and working legal pages first. Then add the access credentials, OAuth test path, and domain-verification materials that your architecture requires. Validate every link, login, and endpoint from a reviewer’s perspective before submission.
The fastest teams make submission readiness part of the build process rather than a launch-week scramble. With Manufact, you can pair deployment, browser-based inspection, and generated marketplace assets in one workflow—so the app you demonstrate is the app reviewers can test. Start from the Manufact dashboard when you are ready to turn a working MCP app into a submission-ready release.