Skip to content

APIs

An API is an entry in the portal catalog that a developer can discover, subscribe to, and call from their own application code. Each one carries a contract, a landing page, documentation, and the subscription plans it offers.

APIs sit in the same catalog as MCP servers and share its subscription and credential machinery. What differs is the contract they publish and how a consumer reaches them.

API types

The portal publishes five API types, each with its own contract format:

Type Contract
REST OpenAPI, as .json, .yaml, or .yml
WebSocket AsyncAPI, as .json, .yaml, or .yml
WebSub AsyncAPI, as .json, .yaml, or .yml
GraphQL A GraphQL schema, as .graphql or .gql
SOAP WSDL, as .wsdl or .xml

The type is fixed when the API is created and determines what its detail page shows and which interactive console it offers.

How APIs differ from MCP servers

An MCP server is another artifact in the same catalog, so most of what you know about APIs carries over. The differences that matter:

API MCP server
Contract OpenAPI, AsyncAPI, GraphQL SDL, or WSDL A definition listing tools, resources, and prompts
Catalog page APIs in the sidebar MCP Servers in the sidebar
Detail page sections Endpoints, Resources or Channels, Scopes MCP Server URL, Tools, Resources, Prompts
Interactive console Try It, or a type-specific tryout client MCP Playground
Consumed by Application code you write An MCP client, configured with the server's URL
Subscribed Through an application that holds the credentials Directly, without an application
Agent visibility The publisher sets it per API Always agent-visible; the catalog marks every server AI Ready

Everything else works the same way. APIs carry tags, labels, icons, subscription plans, and attached documents, and appear in the portal's machine-readable endpoints when the publisher marks them agent-visible.

Note

A portal only serves APIs when its operator lists apis in enabled_types. Leave it out and the sidebar entry, the catalog, and every API route disappear. See Artifact types.

How APIs reach the catalog

Two routes put an API in the catalog.

Registered by an admin

An admin adds the API through Settings → APIs, choosing the type, supplying the details and endpoints, uploading the contract, and attaching documentation. See Manage APIs.

Created through the Management API

The same artifact can be created programmatically, which is the route automation and CI/CD use. It is also the only way to add a SOAP API: the admin wizard's type selector offers no SOAP option, so those are posted with type: SOAP and a WSDL definition. See APIs in the Management API reference.

Where to go next