APIForge

API quality checker and REST API linter

Paste an OpenAPI or Swagger URL and get a per-route list of REST design issues. Each one names the operation, carries a severity and suggests a fix. The same rules produce the 0–100 score.

No spec handy?
  • Rule-based, not AI
  • Per-route issues
  • Fix preview
  • OpenAPI 3.x · Swagger 2.0

Rules the linter runs

The rule set is fixed. These are the checks that produce an issue, with the severity attached to each.

RuleSeveritySuggested fix
Verb-like segment in a path (get, create, update, delete, list, save...)HighUse a noun and the HTTP method: DELETE /users/{id}
GET operation with a request bodyHighUse POST, or move filters to query parameters
Duplicate method and pathHighRemove the repeated operation
camelCase in a pathMediumRename to kebab-case: /user-profile
Action verb in the path that conflicts with the method (create, update, delete, remove)MediumPOST /users instead of POST /users/create
Path deeper than 4 segmentsMediumFlatten the resource chain
No 2xx response documentedMediumDocument 200 or 201 with a schema
No 4xx, 5xx or default response documentedMediumAdd 400, 404 and 500 or default
No URL path version segment anywhereMediumAdd /v1 or document a version header
Singular and plural of the same word across pathsMediumStandardize on plural nouns
Underscore in a path segmentLow/user_profile to /user-profile
Operation without a summary or descriptionLowAdd a summary to each operation

The API quality checklist explains why each check matters.

Related tools and guides

Frequently asked questions

A linter reads the spec and flags design problems without calling the API. This one checks path naming (camelCase, underscores, verbs), GET requests with a body, path depth, missing 2xx and error responses, missing summaries, missing version segments, singular and plural mixing, and duplicate operations.

Spectral runs a ruleset you configure and can be wired into CI. APIForge runs one fixed set of rules in the browser and shows the results next to the operations. There is no ruleset file, no way to switch rules off, and no CLI yet. Use APIForge for a quick review and a linter in CI for enforcement.

High marks problems that break REST semantics or the spec itself: a verb segment in a path, a GET with a body, a duplicate operation. Medium marks missing responses, a missing version segment, deep nesting and naming style. Low marks underscores and missing summaries.

Kebab-case, plural nouns for collections, and HTTP methods for the action. So GET /user-groups/{id}/members, not GET /getUserGroupMembers. The API naming conventions guide explains the reasoning.

HTTP does not define semantics for a GET body. Proxies, caches and some client libraries drop it. The suggested fix is a POST for complex queries, or query parameters for simple filters.

No. It lints the design of the operations it can extract. It does not check schema types, security schemes or examples, and it does not report line numbers. The OpenAPI validator shows whether the file parses and its references resolve.

Not yet. A CLI is on the roadmap but not shipped. Today the checker runs in the browser: paste a spec URL and read the issue list.

It is free, needs no account and is open source under the MIT license. The parse request fetches the spec on the server, returns the operations to your browser and does not save the spec.