The latest APIGit product changes extend AsyncAPI and GraphQL beyond viewing and editing. The next build adds AsyncAPI governance, GraphQL checks in CLI lint, hosted GraphQL mocks, and agent-readable pages for both formats.
This is a release preview. The changes are committed, but the production rollout and a new CLI release are pending. The published CLI 0.5.0 predates these checks. The format support guide separates current production support from the next build.
An AsyncAPI document gains Code, Diff, Governance and Preview tabs. The Governance view reports findings beside the source, with the same rule-selection and jump-to-line workflow used for OpenAPI. AsyncAPI still has no Form editor.
The default menu item keeps its name, OpenAPI Best Practice, and the CLI builtin remains oas-best-practice. The set now includes rules for both OpenAPI and AsyncAPI, with each rule applying to its own format. Choosing the default on an AsyncAPI 2.x or 3.x document runs AsyncAPI checks.
This does not turn every builtin into an AsyncAPI ruleset. OWASP, URL-style and documentation-quality builtins remain OpenAPI-only. The next backend and lint service also extend server lint and account MCP lint_spec to AsyncAPI.
After a CLI release containing these changes, use:
apigit lint events.yaml
apigit lint schema.graphql
apigit lint schema.graphql --fail-severity warn
GraphQL is checked directly, rather than against Spectral rules. Broken SDL produces a graphql-syntax error. Schema issues such as an unknown type produce graphql-schema warnings, because a file may be one part of a larger schema. The default run fails on errors; --fail-severity warn makes those warnings fail it too.
GraphQL does not gain a browser Governance tab or server lint. score, bundle, diff and breaking remain OpenAPI-only. See the CLI examples.
Choose a complete .graphql or .gql schema in Documents & Base Paths when publishing a Spec-based mock. Its default path is /graphql. OpenAPI and GraphQL documents can share the same mock, each at a different base path.
After the backend rollout, the hosted workflow also works from the CLI:
apigit mock publish --name catalog-sandbox --type spec --mount schema.graphql:/graphql
The mock accepts GraphQL queries and mutations over HTTP and returns generated values shaped by the schema. It supports variables, operation names and introspection. An argument matching a returned field is echoed, and the same request produces repeatable values.
Mutations return a result without changing later query results. Subscriptions, batched requests and user-supplied resolvers are outside this engine. The mock validates queries and limits their size, depth and resolved fields.
This is a hosted feature. Local apigit mock serve still accepts OpenAPI files and code-based mocks; it does not run GraphQL schemas. AsyncAPI mocking is not included. Read the GraphQL mock guide for a complete schema, request, response and limits.
AsyncAPI documents and GraphQL schemas each get one generated Markdown page in a published version. The page summarizes channels, messages and payloads for AsyncAPI, or roots, types and fields for GraphQL.
The files appear in llms.txt, llms-full.txt, and document MCP search and outline. The updated Copy page menu exposes View as Markdown for both formats. For public documents, ChatGPT and Claude can read those addresses; protected documents keep their existing access rules.
This is page-level coverage. Separate operation/schema addresses, bundled-spec endpoints and the Skill's operation list remain OpenAPI-only. The account MCP server lists these new files as pages, while its operation and schema tools keep their OpenAPI scope.
OpenAPI, AsyncAPI, GraphQL and Markdown remain ordinary files in one Git repository. Changes are reviewed and committed through the same workflow, and published versions still point at a commit. This build extends the tools that understand each format; it does not add a visual Form editor for AsyncAPI or GraphQL, an event broker, or local GraphQL mocking.
Create, edit and publish AsyncAPI documents and GraphQL schemas alongside OpenAPI. One Redoc 3 viewer, full-panel code editing and a clear guide to what each format supports.
This article explains the different components of a REST API by following a request from end to end. An API client is responsible for assembling and directing an API request to the API server. An API request to a REST API consists of an endpoint, method, parameters, request headers, and a request body. The API server handles authentication, validates input data, retrieves or manipulates data from a database, and returns the appropriate response to the client. An API response typically includes a status code, response headers, and a body. API status codes are used to provide information to the client about the outcome of the request and to help the client understand how to proceed. Response headers and bodies provide additional information and data about the response.
OpenAPI component reuse promotes consistency, reduces duplication, and simplifies maintenance by allowing developers to define schemas, parameters, and responses once and reference them throughout API specifications.
Create a free workspace, add an OpenAPI file and publish your first API document and mock server in minutes.