Overview

Publishing an API makes it visible in the portal catalog so developers can find it, read its documentation, and request access. This guide explains how to prepare an API for publication, choose who can see it, and keep it healthy after launch.

Before you publish

Confirm the following before you publish:

• The API has an OpenAPI specification that passes validation. See Document APIs.
• The API has a clear name, description, and version.
• Authentication and access requirements are documented.
• The API is deployed and reachable in the environments listed in the spec.

Publish an API

1. In Konnect, open Dev Portal and select the PSA Developer Portal.
2. Go to Published APIs and select Publish API.
3. Choose the API and the version you want to publish.
4. Set the visibility:

• Public – Visible to anyone who visits the portal.
• Private – Visible only to signed-in, approved developers.

5. Set the application registration option:

• Disabled – Developers can read the documentation but cannot register.
• Enabled, auto-approve – Registrations are approved automatically.
• Enabled, manual approval – Registrations require approval from an administrator.

6. Select Publish.

After publishing, open the API in the portal and confirm that the documentation renders correctly and that the endpoints, examples, and authentication details look as expected.

Control access

Match access settings to the sensitivity of the API. Public visibility with manual approval works well for partner APIs, while internal APIs should be private. Review the list of developers and applications with access on a regular schedule, and remove access that is no longer needed.

Version your APIs

Versioning lets you improve an API without breaking the developers who depend on it.

• Use a major version (for example, v1, v2) for breaking changes.
• Make additive, backward-compatible changes within the existing version.
• Publish each major version separately so developers can choose when to migrate.
• Announce deprecations early and give developers a defined migration window.

See Versioning for the full policy and examples.

Keep published APIs up to date

• Update the specification whenever the API changes, then republish.
• Mark retired versions as deprecated before you unpublish them.
• Monitor usage to understand which versions and endpoints developers rely on.
• Communicate changes through release notes and direct notices to registered developers.

Unpublish an API

To retire an API, first mark it as deprecated and notify developers. When the migration window ends, open the API under Published APIs and select Unpublish. The documentation is removed from the portal, and existing credentials for the API stop being usable according to your gateway configuration.

Next steps

• Review Versioning before releasing a breaking change.
• Return to the Guides overview for other topics.