Apifox Helper

Problem

Manually turning a selected endpoint into an OpenAPI document often means filling in method, path, parameters, requestBody, and responses, then choosing where to import it in Apifox. Apifox Helper targets that workflow: it works only on the user-selected code, does not scan the whole project by default, converts the selection into a minimal usable OpenAPI 3 document, and imports it into the target project via a helper script.

How it works

It first checks config.json for accessToken and projectId. If either value is missing, it stops and asks the user to complete the configuration instead of continuing with incomplete credentials. It then extracts the HTTP method, route path, headers, path parameters, query parameters, request body, likely success response shape, and controller or module tags. Endpoint names are derived in priority order from comments, framework summary annotations, and function name plus route semantics. The generated document keeps only necessary structures: summary, paths, parameters, requestBody, and at least one minimal response, without inventing complex schemas. Import uses scripts/import_openapi.py against the Apifox OpenAPI import endpoint, preferring standard input over temporary files. If a file is unavoidable, it is written into the current project directory.

Boundaries

This is useful for syncing a single endpoint, route handler, or controller snippet into Apifox. When an import location is needed, moduleId can be passed; targetEndpointFolderId must be used together with moduleId, and is ignored if supplied alone. The overwrite behavior defaults to OVERWRITE_EXISTING, and user descriptions can map to AUTO_MERGE, KEEP_EXISTING, or CREATE_NEW. If the HTTP method or route path is unclear, the skill asks before proceeding rather than guessing.