API tooling · Export
PYD ENTERPRISES and SwaggerHub
Publish synthesized OpenAPI definitions to SmartBear SwaggerHub so API governance, style rules and versioning apply to specs extracted from legacy code.
SwaggerHub
API tooling
1paths:2 /loans/{loanId}/accrual:3 get:4 operationId: getDailyAccrual5 x-pyd-source: LNINQ01.cbl:220-268 (CICS TRANSID LNIQ)6 parameters:7 - name: loanId8 in: path9 required: true10 schema: { type: string, pattern: "^LN[0-9]{7}$" }
Extracted APIs deserve the same governance as designed ones
Enterprises that run SmartBear SwaggerHub usually already have API standards: naming conventions, required error models, security schemes, versioning rules. The interfaces PYD ENTERPRISES extracts from legacy code are the starting contracts for new services, so they should pass through the same governance before anyone builds against them.
PYD ENTERPRISES exports one OpenAPI document per bounded interface (for example one per CICS transaction group or per WCF service) and can publish each one as an API definition in your SwaggerHub organization. Definitions carry vendor extensions that preserve provenance: x-pyd-source on operations and schemas points to the legacy program and line range, and x-pyd-rule links properties to the business rules that constrain them.
OpenAPI version and style
PYD ENTERPRISES' native output is OpenAPI 3.1, whose schema dialect is aligned with JSON Schema 2020-12. If your SwaggerHub organization or downstream tooling still standardizes on OpenAPI 3.0, PYD ENTERPRISES can emit a 3.0.3 variant: type: [string, "null"] becomes nullable: true, examples arrays become a single example, and constructs with no 3.0 equivalent are listed in the export report rather than dropped silently.
Style rules are best enforced before publishing. PYD ENTERPRISES lets you set naming conventions for paths and properties (for example kebab-case paths, camelCase properties derived from COBOL names like LN-PRIN-BAL to principalBalance), a standard error schema and a security scheme, so published definitions arrive already close to your guidelines.
Publishing and versioning
Publishing can happen through the SwaggerHub registry interface using an API key you issue for a service account, or by exporting YAML files that your API team imports manually. Each PYD ENTERPRISES baseline maps to a definition version, so the version history in SwaggerHub mirrors the history of approved scans. Definitions are created unpublished, as drafts, so your API owners decide when an extracted contract becomes official. For SwaggerHub On-Premise installations inside your network, no traffic leaves your perimeter.
FAQ
SwaggerHub questions.
Can we publish to SwaggerHub without giving PYD ENTERPRISES network access to it?
Yes. Export the YAML files and import them through your normal process. The provenance extensions travel inside the files.
Will the x-pyd extensions break other tools?
No. OpenAPI allows x- extensions anywhere they are used, and tools that do not understand them ignore them. You can also strip them at export.
What if our standards require OpenAPI 3.0?
Choose the 3.0.3 compatibility output. PYD ENTERPRISES converts what has a 3.0 equivalent and lists anything that does not in the export report.
RELATED INTEGRATIONS
See the SwaggerHub flow on your own code.
Run PYD ENTERPRISES on 100,000 lines of COBOL or Java in your private VPC and review OpenAPI specs and DMN tables tomorrow.