# API Designer > Author OpenAPI without writing YAML by hand, import what you already have, and turn the spec into a live, governed API on the same gateway with one click. The same spec drives Swagger UI in the Portal, JSON, YAML, PDF, HTML, and Markdown — in every language your consumers speak. *API Designer* ## Design the API. Ship the proxy. One click apart. [Request a demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) **Highlights** - **Specs** — OpenAPI 3 · Swagger 2 · WSDL - **Output** — Live API Proxy + Portal docs - **Round-trip** — Spec ↔ Proxy in sync --- ## Capabilities ### 01 · Author OpenAPI without writing YAML by hand. Edit the spec the way you think about an API — endpoints, request bodies, responses, data models — through a guided editor with a live YAML or JSON view next to it. Mistakes catch as you type, and the same screen previews exactly what consumers will see in the Portal. - Side-by-side design view and code view — switch any time - Endpoints, parameters, headers, request bodies, responses — all first-class - Reusable data models with properties, examples, and validation rules - Inline validation against the OpenAPI Specification as you type - Multi-server definitions for dev, test, and production base URLs - Contact, license, and terms-of-service captured on the same screen - Spec-level authentication setup — no separate workflow - Filter long specs by path or data model — built for big APIs **Concepts:** `Design view` · `Code view` · `Live validation` · `Data models` · `Multi-server` ### 02 · Begin from scratch — or bring in what you already have. Open the Designer and pick a starting point. Start with a blank API and build it endpoint by endpoint, or import an existing spec from a URL or a file and pick up where someone else left off. OpenAPI 3, Swagger 2, and WSDL all land in the same editor. - Blank API — start with a clean spec and grow it as you go - Import from a URL — the editor fetches and parses the spec for you - Import from a file — drop in a YAML, JSON, or WSDL file - OpenAPI 3.0.x supported end to end - Swagger 2.x supported and upgradable to OpenAPI 3 with one action - WSDL imports converted to an OpenAPI surface automatically - Re-import on top of an existing spec — keeps your customizations - Side-by-side diff before applying an imported change **Concepts:** `Blank API` · `Import from URL` · `Import from file` · `OpenAPI 3` · `Swagger 2` · `WSDL` ### 03 · The spec doesn't stop at a YAML file. One click and it's a live, governed API. Every other design tool produces a YAML file you then have to wire into your gateway. Apinizer collapses that step. Hit Create API Proxy and the spec becomes a real, running, fully-governed API — endpoints, methods, request and response schemas all mapped to a Worker pod, behind the same authentication, rate limiting, audit, and analytics stack that protects every other Apinizer API. - One action turns a spec into a live API Proxy on the gateway - Every path becomes a routable endpoint, every method an operation - Request and response schemas attached for validation at runtime - Same policy stack as a hand-built proxy — auth, throttling, audit, analytics - Same observability — every call captured with full request context - Pick the environment — dev, test, or production — at proxy creation - Routes traffic across the same Worker pods as every other Apinizer API - From design to live endpoint in seconds — no separate deploy pipeline **Concepts:** `One click` · `Full proxy` · `All endpoints` · `All schemas` · `Same gateway` · `Same policies` > Turn on MCP at proxy creation and AI agents discover the new API the moment it goes live — no second publishing step. ### 04 · Edit the spec. The proxy follows. No copy-paste. When you change a spec — add a path, rename a field, update a schema — the connected API Proxy picks the change up automatically. Endpoints, methods, and schemas stay aligned. The policies you attached by hand stay in place. No drift, no parallel files, no manual reconciliation between what the spec says and what production is actually serving. - Re-apply the spec and the proxy updates in place - Endpoints, methods, and schemas re-synced from the spec - Attached policies — authentication, throttling, mediation — preserved - Spec and proxy share one identifier — never two sources of truth - Optional approval step before a re-sync hits production - Roll back the spec, roll back the proxy — one operation - Version history on every spec change - Promote the same spec across dev, test, and production environments **Concepts:** `Auto-sync` · `No drift` · `Policies preserved` · `Versioned` · `Promote across environments` ### 05 · Drop in a WSDL. Get a modern OpenAPI surface. Most enterprises sit on a long tail of SOAP services that aren't going anywhere. The Designer takes a WSDL — by URL or file — and produces an OpenAPI spec mapped to the original operations. From there it's the same one-click flow: ship a REST proxy in front of the SOAP backend, document it in the Portal, and let new consumers move forward without the old contracts. - Drop in a WSDL by URL or file - Operations, types, and faults mapped into an OpenAPI surface - Generate a REST proxy in front of the SOAP service — SOAP-as-REST - Existing SOAP consumers untouched — new consumers move to REST - Round-trip editing — edit the OpenAPI side without losing WSDL alignment - Same Designer canvas — no separate WSDL tool to learn - Documentation rendered in the Portal exactly like any other API - Mediation handled by the gateway — no glue services to maintain **Concepts:** `WSDL import` · `SOAP-as-REST` · `Round-trip editing` · `Legacy modernization` ### 06 · Every spec ships its own documentation — in every format your team needs. Documentation isn't a separate project anymore. The same spec drives a Swagger UI render inside the Portal, exports to JSON or YAML for tool compatibility, and packages into PDF, HTML, or Markdown when the legal or partner team asks. Turkish and English ship by default, and a third language is one toggle away. - Swagger UI rendered live inside the API Portal - Export the raw spec as JSON or YAML for any external tooling - Export as PDF or HTML for partners, auditors, or procurement - Export as Markdown for your internal wiki or developer hub - Turkish and English documentation generated from the same spec - Add a third language with one toggle — no extra authoring - Code samples for cURL and popular languages, generated automatically - Documentation updates the moment the spec is re-applied — never stale **Concepts:** `Swagger UI` · `JSON · YAML` · `PDF · HTML · Markdown` · `Turkish + English` · `Code samples` ### 07 · Treat your API contract like the rest of your codebase. OpenAPI is plain YAML or JSON — and the Designer is designed to play well with the source-control workflow your team already runs. Diff the spec in your repo, validate in CI, ship through APIops. Pull-request reviews on API contracts work the same way reviews on code do. - Spec stored as plain YAML or JSON — diff-friendly out of the box - Validate specs in CI — reject broken contracts before they merge - APIops apply pushes the spec — same auth, same audit as the UI - Promote a reviewed spec from dev to production through your pipeline - Pull-request reviews on API contracts, not just on glue code - Versioning lives in your repo — no parallel version registry - Templates and shared schemas reusable across multiple specs - Branch protections on API contracts — no surprise breaking changes **Concepts:** `YAML · JSON` · `Diff-friendly` · `Validate in CI` · `APIops apply` · `Promote through pipeline` ### 08 · From the editor to a working Try-It console in seconds. When the proxy goes live, the spec it came from already powers the Portal catalog page. Consumers find the new API in search, open the documentation, and run a Try-It call with the right authentication flow already wired up — without anyone publishing anything by hand. Humans and AI agents discover the new API on the same surface. - Auto-publish to the API Portal the moment the proxy goes live - Catalog entry, search indexing, and category placement handled for you - Try-It console wired to the right authentication flow automatically - Versioning, deprecation badges, and changelogs surfaced to consumers - Same surface for human developers and AI agents over MCP - Pick visibility per audience — open, signed-in only, or approved partners - Code samples regenerated from the latest spec - Subscription and credential flow inherited from the Portal — nothing to wire **Concepts:** `Auto-publish` · `Try-It console` · `Auth-aware` · `Versioning` · `Same surface for AI agents` > The Portal catalog this spec lands in is the same catalog AI agents browse over MCP — one design pass, two audiences. --- ## Use cases ### Design before code, ship before glue Agree the contract in the Designer, generate the proxy, let engineering build behind the spec. The Portal already shows the contract live — partners and AI agents can read it before a single backend line exists. - OpenAPI as the single source of truth - Live Portal preview while the spec is still in flight - One-click proxy generation when the design is ready - Auto-versioning of breaking and non-breaking changes ### Move a SOAP estate to a modern developer surface Import the WSDL, expose REST, document in OpenAPI. Existing SOAP consumers stay where they are; new consumers and AI agents get a REST API and a Try-It console — without a code rewrite. - WSDL imported and converted to an OpenAPI surface - SOAP-as-REST proxies generated in one step - Mixed protocol exposure — SOAP, REST, gRPC — on the same gateway - Round-trip editing keeps the OpenAPI side aligned with the WSDL ### Treat API contracts like code, ship them like code Keep the spec in your repo, diff it in pull requests, validate in CI, apply via APIops. Reviewers see the API change before it goes live — and rolling back is one revert away. - Plain YAML or JSON specs that diff cleanly - Validate specs in CI before merge - APIops apply pushes the spec with full audit - Promote a reviewed spec from dev to production ### Make the spec readable by an AI consumer The same OpenAPI spec the Designer produces is the spec AI agents read over MCP. Discovery, documentation, and Try-It happen on one canvas — humans on the UI, agents on the protocol. - OpenAPI is the discovery format for both humans and agents - Same auth and access controls behind the spec - Agents can run Try-It calls under the same governance - Every agent call captured in the same audit pipeline --- ## What ships in the box ### Authoring - Side-by-side design view and code view - OpenAPI 3.0.x and Swagger 2.x - YAML and JSON formats with inline validation - Reusable data models with properties and examples - Multi-server definitions for dev, test, and production - Spec-level authentication and security setup - Filter long specs by path or data model - Blank-API and Import-from-URL or file start options ### Output and integration - One-click API Proxy generation on the same gateway - Spec-to-proxy round trip with policy preservation - WSDL import with SOAP-as-REST exposure - Auto-publish to the API Portal with Try-It console - Swagger UI render, JSON, YAML, PDF, HTML, Markdown export - Turkish and English documentation by default - Code samples for cURL and popular languages - APIops apply with spec-as-code workflows --- ## Resources - [Designer guide](https://apinizer.com/developers/docs) — Spec authoring, data model editing, and one-click API Proxy generation — from blank API to live endpoint. - [OpenAPI samples](https://apinizer.com/developers/docs/designer-samples) — Reference specs you can import as starting points — REST, async, and SOAP-imported examples. - [WSDL to REST](https://apinizer.com/developers/docs/wsdl-to-rest) — Bring a SOAP service forward — import the WSDL, expose a REST surface, document it in the Portal. - [Spec-as-code with APIops](https://apinizer.com/developers/docs/apiops) — Diff in your repo, validate in CI, push through APIops apply — without leaving the developer workflow. - [Designer + Portal walkthrough](https://apinizer.com/products/api-portal) — From the Designer canvas to a working Try-It console in the Portal — in under two minutes. - [Architecture](https://docs.apinizer.com/en/concepts/architecture) — How the Designer fits next to the Manager, the Worker, and the Portal — one source of truth across them. --- ## Next step *Design-to-runtime* **Design once. Ship the API, not the YAML.** See the Designer turn an OpenAPI spec into a live, governed proxy — with Portal docs, Try-It, and Swagger UI ready the moment it goes up. [Book a Demo](https://calendly.com/apinizer/15min) · [Read the docs](https://apinizer.com/developers/docs) --- ## Links - Products: https://apinizer.com/products - AI Gateway: https://apinizer.com/products/ai-gateway - Solutions: https://apinizer.com/solutions - Pricing: https://apinizer.com/pricing - Developers: https://apinizer.com/developers - Documentation: https://docs.apinizer.com/index-en - Blog: https://apinizer.com/blog - Contact: https://apinizer.com/company/contact © 2026 Apinizer. All rights reserved.