API Designer is a free, browser-based visual tool for designing REST APIs and generating valid OpenAPI 3.0 specifications. Define your endpoints, request/response schemas, path parameters, and authentication method using a form-driven UI — the tool regenerates the YAML preview live as you type. Export as a standard OpenAPI 3.0 YAML file (compatible with Swagger UI, Redoc, and API gateways) or as a Postman Collection v2.1 JSON ready to import and test. No account, no server, no data sent anywhere — everything runs in your browser.
Use this tool to design any REST API from scratch: internal microservices, public APIs, webhook receivers, mobile backend APIs, or SaaS platform APIs. For each endpoint you define: the HTTP method (GET, POST, PUT, PATCH, DELETE), the path (with optional {param} placeholders for path variables), a summary and description, request body fields (for POST/PUT/PATCH) with field names, types, required flags, and descriptions, and response definitions with status codes and descriptions.
The left sidebar holds your API Info (name, version, base URL, description), your auth method selector, and the full endpoint list with color-coded method badges. The main panel shows the editor for the selected endpoint. Click any endpoint in the sidebar to switch to it. Use '+ Add Endpoint' to start a new one.
The bottom panel shows a live-regenerating OpenAPI 3.0 YAML document. Every change you make — editing a path, adding a body field, toggling required, switching auth method — immediately updates the YAML.
The generated YAML includes all required OpenAPI 3.0 sections: openapi: "3.0.0", info block (title, version, description), servers array (your base URL), security block (if auth is configured), paths with HTTP operations and operationIds, parameters (for path params), requestBody with application/json schema and a properties block listing each field, responses with status codes, and a components/securitySchemes section.
The generated YAML is valid — paste it into Swagger UI's Petstore editor (editor.swagger.io) to verify, import it into Postman, or feed it to openapi-generator-cli to generate server stubs.
Click 'Download Postman Collection' to export a Postman Collection v2.1 JSON file. The collection contains all your endpoints as request items, with:
• Pre-filled request bodies: string fields get "", number/integer get 0, boolean gets false, array gets [], object gets {} • Authentication header: Authorization: Bearer {{token}} for Bearer, your custom header for API Key, or Authorization: Basic {{basicAuth}} for Basic Auth • Content-Type: application/json header on all POST/PUT/PATCH requests • Path variables listed under the URL variable block • A {{baseUrl}} collection variable pre-set to your configured base URL
In Postman: File → Import → select the JSON file. Your full API appears as a collection ready to run against any environment.
The tool opens with a pre-loaded 'Task Management API' at /api/v1 with Bearer Token auth and 3 example endpoints:
• GET /tasks — List tasks, with a 200 and 401 response • POST /tasks — Create task, with 3 body fields: title (string, required), description (string, optional), priority (string, optional) and 201/400/401 responses • DELETE /tasks/{id} — Delete task with a path parameter 'id', and 204/404/401 responses
Explore the generated YAML to see how each endpoint maps to the OpenAPI structure. Edit any field and watch the YAML update instantly. This gives you a concrete starting point to modify into your own API design.
Yes. The YAML output follows the OpenAPI 3.0.0 specification — it includes the correct openapi version string, a valid info block, properly structured paths with operation objects, parameters in the correct format, requestBody with application/json content and a JSON Schema properties block, and securitySchemes in the components section. You can paste it into editor.swagger.io to validate it, import it into Postman, or run it through openapi-generator-cli. For production APIs you may want to add example values, additional response schemas (JSON body definitions for each response), and $ref references for shared schemas — the tool covers the essential structure that makes a valid and useful spec.
Yes. Download the YAML file and either paste it into editor.swagger.io for a quick preview, or serve it with a local Swagger UI instance. If you're using Next.js, install swagger-ui-react and import the YAML. If you're using Express, use the swagger-ui-express middleware and point it at your yaml file. The generated spec includes all required fields for Swagger UI to render the interactive documentation — endpoint summaries, parameter lists, request body schemas, and response definitions all appear in the UI. If you have auth configured, the "Authorize" button in Swagger UI will appear with the correct security scheme.
No — this tool is specifically for REST API design and OpenAPI 3.0 specifications. GraphQL uses a fundamentally different design model (a typed schema with Query/Mutation/Subscription types, resolvers, and the GraphQL SDL format) that is incompatible with REST/OpenAPI concepts. For GraphQL schema design, tools like Apollo Studio, GraphQL Playground, or the GraphQL Schema Language in any text editor are the right choice. If you're deciding between REST and GraphQL for a new project, REST with OpenAPI is generally the better default: it's simpler to implement, cacheable at the HTTP layer, and supported by every HTTP client without a special library.
The current version of the tool does not persist designs between sessions — refreshing the page resets to the Task Management API example. To save your work: use the "Download OpenAPI YAML" button to export your spec, then re-import it by manually pasting content into the editor in a future session, or keep the YAML file as your source of truth in your project repository. A future version may add localStorage persistence or file import. The downloaded OpenAPI YAML is the portable, version-controllable artifact — commit it to your repo alongside your API code.
Path parameters are embedded in the URL path itself and identify a specific resource: /tasks/{id} — the {id} is a path parameter. They are required and must be present for the URL to be valid. Path parameters are auto-detected by the API Designer when you type {name} in the path field — they appear in the Path Parameters section and are included in the OpenAPI spec with "in: path" and "required: true". Query parameters appear after the ? in the URL: /tasks?status=open&page=2. They are optional filters, pagination controls, search terms, or other modifiers. The API Designer currently handles path parameters automatically. Query parameters should be documented in the endpoint description or added to the responses section until a dedicated query param editor is added in a future update.