For Agents
Convert Swagger 2.0 definitions to OpenAPI 3.0.x and validate OpenAPI 3.0.x specs through a hosted service.
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Swagger2OpenAPI Converter, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
What an agent can do with Swagger2OpenAPI Converter API.
Convert a Swagger 2.0 definition referenced by URL into OpenAPI 3.0.x JSON
Convert a Swagger 2.0 definition supplied directly in the request body
Validate an OpenAPI 3.0.x definition referenced by URL against the schema
Validate an OpenAPI 3.0.x definition supplied in the request body and surface schema errors
GET STARTED
Use for: I need to convert a Swagger 2.0 spec to OpenAPI 3.0, Validate an OpenAPI 3.0.x definition I just edited, Check whether a remote OpenAPI URL is valid, Get a validity badge for a spec to embed in a README
Not supported: Does not handle code generation, mocking, hosting, or formats other than Swagger 2.0 and OpenAPI 3.0.x — use for Swagger-to-OpenAPI conversion and OpenAPI 3.0.x validation only.
Jentic publishes the only available OpenAPI document for Swagger2OpenAPI Converter, keeping it validated and agent-ready.
Jentic publishes the only available OpenAPI specification for Swagger2OpenAPI Converter, keeping it validated and agent-ready. Mermade's hosted Swagger2OpenAPI service converts legacy Swagger 2.0 definitions to OpenAPI 3.0.x and validates 3.0.x specs against the official schema. It accepts a definition either by URL or directly in the request body, and exposes a status check plus a shields.io-style validity badge so CI pipelines and docs sites can surface conversion and validation results without running the converter locally.
Render an SVG validity badge for embedding in repository READMEs
Check service health to gate CI pipelines on converter availability
Patterns agents use Swagger2OpenAPI Converter API for, with concrete tasks.
★ Legacy Swagger 2.0 Migration
Teams maintaining historical Swagger 2.0 contracts can migrate them to OpenAPI 3.0.x by calling GET /convert with a URL pointing at the old definition or POST /convert with the body inline. The hosted service returns the converted JSON, ready to drop into a modern toolchain. Migrations of small APIs typically take minutes once the call is wired in.
Call POST /convert with the Swagger 2.0 JSON in the body to receive the OpenAPI 3.0.x conversion.
CI Validation of OpenAPI Specs
Build pipelines that publish OpenAPI specs can fail fast on schema regressions by calling GET /validate with the artefact URL or POST /validate with the spec in the body. The response surfaces schema-level errors so the pipeline can block a release when the contract is no longer valid.
Call POST /validate with the freshly built openapi.json in the body and fail the CI step if the response reports schema errors.
README Validity Badge
Open-source maintainers publishing OpenAPI specs in their repositories can add a hosted validity badge by linking GET /badge with the spec URL. The endpoint returns a redirect to a shields.io-style SVG that updates as the source spec changes, giving readers a quick signal of contract health.
Call GET /badge with the public spec URL and embed the resulting redirect URL in the project README.
Agent-Driven Spec Hygiene
An AI agent maintaining an internal API catalogue can use the converter to normalise newly imported specs to OpenAPI 3.0.x and validate them in the same pass. Through Jentic the agent finds the convert and validate operations, executes them, and stores the cleaned spec back in the catalogue without writing custom converter code.
Search Jentic for 'convert Swagger 2.0 to OpenAPI 3.0', execute POST /convert with the imported spec, then POST /validate on the result and write back the cleaned definition.
6 endpoints — jentic publishes the only available openapi specification for swagger2openapi converter, keeping it validated and agent-ready.
METHOD
PATH
DESCRIPTION
/status
Check converter service status
/convert
Convert a Swagger 2.0 URL to OpenAPI 3.0.x
/convert
Convert a Swagger 2.0 body to OpenAPI 3.0.x
/validate
Validate an OpenAPI 3.0.x URL
/validate
Validate an OpenAPI 3.0.x body
/badge
Return a redirect to a validity badge SVG
/status
Check converter service status
/convert
Convert a Swagger 2.0 URL to OpenAPI 3.0.x
/convert
Convert a Swagger 2.0 body to OpenAPI 3.0.x
/validate
Validate an OpenAPI 3.0.x URL
/validate
Validate an OpenAPI 3.0.x body
Three things that make agents converge on Jentic-routed access.
Credential isolation
The Mermade endpoint is unauthenticated, but Jentic still proxies the call so request shaping, logging, and quotas apply consistently with authenticated APIs in the same workflow.
Intent-based discovery
Agents search Jentic with intents like 'convert Swagger 2.0 to OpenAPI 3.0' and receive POST /convert with the body schema, or 'validate an OpenAPI spec' for /validate.
Time to first call
Direct integration: under a day, mostly spent on input fetching and error handling. Through Jentic: a few minutes.
Alternatives and complements available in the Jentic catalogue.
Swagger Generator API
Generate client SDKs and server stubs from an OpenAPI definition
Use after converting a spec when the next step is producing client or server code from the cleaned OpenAPI 3.0 definition.
APIMatic API
Commercial API definition transformation, validation, and code generation
Use when the team needs an enterprise SLA, support for additional spec formats (RAML, API Blueprint), or end-to-end SDK generation.
Docker Engine API
Run validation steps in containers as part of a CI pipeline
Use when CI needs to orchestrate spec validation alongside container builds in the same pipeline.
Specific to using Swagger2OpenAPI Converter API through Jentic.
Why is there no official OpenAPI spec for Swagger2OpenAPI Converter?
Mermade does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Swagger2OpenAPI Converter via structured tooling. It is validated against the live API and kept up to date. Get started at https://app.jentic.com/sign-up.
What authentication does the Swagger2OpenAPI Converter use?
The hosted service does not declare a security scheme; the documented endpoints are publicly callable. Through Jentic, calls are still routed through the gateway so tenants get logging and request shaping even when the upstream is unauthenticated.
Can I send the Swagger spec directly in the body instead of by URL?
Yes. POST /convert accepts the Swagger 2.0 definition in the request body and POST /validate accepts an OpenAPI 3.0.x definition the same way, which is useful when the spec is not yet published at a public URL.
What are the rate limits for the Swagger2OpenAPI Converter?
The OpenAPI spec does not declare rate limits. The hosted service is community-run on a single host, so high-volume callers should self-throttle and prefer the npm package swagger2openapi for batch jobs rather than calling the API in a tight loop.
How do I convert a Swagger 2.0 spec through Jentic?
Install the SDK with pip install jentic, search for 'convert Swagger 2.0 to OpenAPI 3.0', load the POST /convert operation, and execute it with the Swagger JSON in the body. Jentic returns the converted OpenAPI 3.0.x payload.
Does the converter return validation errors when the input is broken?
Yes. POST /validate returns a structured error response listing the schema violations found, so callers can use it to gate CI pipelines or fail a publish step when the underlying spec is invalid.
/badge
Return a redirect to a validity badge SVG