How to Publish a Business Plugin in the ChatGPT Directory

A personal plugin used by the founder, a workspace tool for staff and a customer-facing public release serve different audiences. Confirm the audience before assembling a public listing. For an internal workflow, a public package may expose a promise the business does not intend to support. For a customer-facing tool, a workspace demonstration does not establish access outside the organisation. Test using the audience you actually expect. Write the purpose in one sentence and define supported countries or audience restrictions where applicable. Keep that purpose consistent across the package, tools, test cases and customer instructions.

OpenAI's remote-server review requirements cover verification, management permissions and endpoint requirements. Check the current access available to the publishing organisation before planning the release date. Record who controls the publisher identity, source accounts, server hosting and support contact. If a supplier builds the integration, agree these responsibilities before submission. A business should know who can respond to review feedback and maintain the published service. Keep this record operational. It should name an owner for each dependency and describe how another authorised team member can take over. The project's original developer should not be the only person who knows which account controls the release.

Use the current package documentation rather than an older tutorial. The portable layout uses a root plugin.json; the documented Codex compatibility layout remains supported. The components and manifest must agree. Keep a versioned copy of the package and a short description of what changed. A developer should be able to identify exactly which files correspond to the tested candidate. Avoid including temporary exports, unrelated instructions or credentials. Check the public description against actual behaviour. If the plugin retrieves status, do not advertise cancellation or booking changes that have not been implemented and verified. A precise supported task is easier to review and easier for customers to understand.

Record the deployed endpoint and the systems it reads or changes. Include the intended account boundaries and the current tool definitions. A local demonstration is not a substitute for testing the release endpoint. Use the same candidate when recording test results and preparing review material. If the handler or schema changes afterwards, decide which cases must be rerun. Otherwise the evidence describes a different service from the one a reviewer encounters. Verify basic operational behaviour: source unavailable, invalid input and expired access. A business owner does not need to inspect every network request, but should understand how those failures appear to users and the team.

Write review cases around observable behaviour. For a status plugin, a positive case might retrieve the current stage of a permitted request. A negative case might ask for another customer's request or an unsupported cancellation. For each case, record the sample data, prompt, expected tool and expected result. Distinguish a clarification from a refusal and from a successful read. A vague expectation such as works correctly will not help your own team diagnose a difference. Run the cases with the dedicated review account. A developer's broad account may pass while the supplied reviewer account lacks the sample records. Make the evidence reproducible from the access you actually provide.

Keep private access material in the appropriate secure channel. Public assets should explain functionality without exposing real customer records or secrets. Use approved sample data in the walkthrough. Rehearse the sign-in and first task from a clean environment. Check whether the reviewer can reach the account, see the sample record and complete the expected operation without assistance from a staff member waiting on a message. The walkthrough should follow the tested candidate and show its boundaries. A concise demonstration of a supported task and a sensible unsupported response is more useful than a long product pitch. Keep the recording accessible to the intended reviewer.

Give the team separate milestones: prepared, uploaded, checks reviewed, submitted, approved and published. Attach evidence to each. A valid upload is not an approval, and approval is not the same as a customer-accessible listing. When feedback arrives, map it to a change and an acceptance case. Avoid editing several unrelated capabilities while resolving a specific finding. Record the updated package and which checks were repeated. Do not promise a review turnaround that the documentation does not guarantee. Plan customer communication around a confirmed public outcome. A supplier can commit to preparation work without controlling the external decision.

After publication, open the direct listing link and check access from a suitable ordinary account. Confirm the displayed purpose, publisher identity and supported task. A result visible in the publisher's dashboard alone is incomplete evidence. Repeat a small set of customer journeys against the published version. For a status tool, verify both the permitted record and the access boundary. Keep the existing support route available if a customer cannot connect. Then follow the discovery article to plan distribution. Publication establishes an available product; acquiring customers is another job.

Classify updates by what changed: public copy, packaged instructions, server configuration or hosted tool behaviour. Follow the current documented update route for that change. Do not assume all updates use the same process. Keep release notes focused on observable behaviour. Record changed fields, supported tasks or access rules and the cases used to verify them. That makes support and future review easier. Revisit the evidence folder when a source system changes. The customer promise may stay the same while the underlying integration needs work. Retaining the tested contract gives the team a clear target.

Does a personal plugin appear publicly? A personal connection and public publication are different routes. Verify the release intended for customers outside your workspace. Can we guarantee approval in a client proposal? Promise the preparation and verification work you control. Approval is an external review decision. What is the most useful preparation? A tested candidate with clear ownership, reproducible cases and working reviewer access.

Requirements checked on 5 October 2026. The evidence-folder method is an original operating recommendation. 13labs plugin development can include the agreed submission preparation and handover, with publication dependencies made explicit in the scope.