Skip to content

Consume an API

Calling an API published in the API Portal & MCP Hub takes two things: the endpoint URL, and the right credentials in the right headers. This page covers the credentials—which ones exist, how to tell which an API expects, and where to get each.

Three distinct credentials are involved. The portal issues the subscription token and the API key; OAuth2 access tokens are issued by a key manager, which the portal only proxies requests to. They aren't alternatives to each other—an API can require one, two, or all three at once.

Credential What it proves Where it comes from Header
Subscription token You're subscribed to this API under a plan, so the gateway knows which rate limit to apply Subscribing to a plan on the API's overview page The header named in the API's specification, commonly Subscription-Key
API key You're an authorized caller of this specific API The API Keys page for that API apikey, or the header named in the specification
OAuth2 access token Your application holds valid client credentials Issued by a key manager; requested through your application's Manage Keys page Authorization: Bearer <token>

Work out what an API expects

Read the API's own specification—it's authoritative, and the portal derives its UI from it.

  1. Open the API and click Documentation, then API Definition.
  2. Read securitySchemes for what the API defines: a scheme of type oauth2 means an access token, and one of type apiKey names its exact header in the name field.
  3. Read the security entries for what it requires. A root-level security block applies to every operation; an operation can override it with its own. A scheme that's defined but never referenced isn't required.
  4. Check for a subscription-key parameter. When the specification declares one, the portal shows a subscription token after you subscribe, along with the header to send it in.

Two shortcuts on the API's overview page tell you the same thing faster:

  • An API Keys button appears for REST and WebSocket APIs whose specification declares API key security. The portal offers no key generation in the UI for GraphQL, SOAP, or MCP artifacts, even when their specification declares an apiKey scheme. For those, use the Management API: API Keys for GraphQL and SOAP APIs, and MCP Server Keys for MCP servers.
  • A Subscription plans panel appears only for APIs with plans, which is what a subscription token comes from.

The per-API Markdown document at /{orgName}/views/{viewName}/api/{apiHandle}.md spells out the authentication steps in prose, generated from the same specification. It's the quickest read of the three.

Get each credential

Subscription token

Subscribe to the API under a plan. The portal shows the token once, in a dialog, right after the subscription is created.

You can come back to it later: on the API's overview page, click View subscription on the plan you hold, then reveal or copy the token. The same dialog lets you regenerate the token—which invalidates the old one immediately—suspend the subscription, or unsubscribe.

API key

Generate one from the API Keys page for that API, reachable from the API Keys button on the overview page or the sidebar submenu. See Manage API Keys for the generate, rotate, and revoke lifecycle, and Consume an API Secured with an API Key for using it in a request.

OAuth2 access token

This one needs the most setup, because the OAuth application lives in a key manager rather than in the portal. In outline: create the OAuth application in your key manager, create an application in the portal, link the client ID to it, then generate a token. See Consume an API Secured with OAuth2 for the full sequence.

Try before you wire it up

For REST APIs, the Try It console on the documentation page sends real requests from your browser. Paste the same credentials you'd use from code—it's the fastest way to confirm you have the right header names before writing a client.