Sign in
catalog

Get API details — metadata, auth schemes, servers, and optional spec sections

Returns API metadata enriched with selected OpenAPI spec sections.

Default response (no ?sections=) includes:

  • Summary fields: id, name, vendor, description, base_url, operation_count, overlay_count
  • info — title, version, contact, license, terms of service
  • servers — base URLs and variables (merged from spec + confirmed overlays)
  • security_schemes — security scheme definitions (merged from spec + confirmed overlays), plus security_required (global security requirements)
  • credentials_configured — list of auth_types that already have a credential bound. Use this to build a credential-setup UI: iterate security_schemes, check each key against security_schemes (each scheme has a type field) to determine which auth types need credentials. to fill in the required fields and POST to /credentials.

Credential setup flow:

  1. Call GET /apis/{api_id} — inspect security_schemes and credentials_configured
  2. For each unconfigured scheme, determine required fields from the scheme type:
    • http bearer → secret (token)
    • http basic → secret (password) + optional identity (username)
    • apiKey → secret (key value); if compound, check scheme names for Secret/Identity
  3. Prompt user for values, then POST /credentials with api_id, auth_type, value (and identity if needed).
  4. Verify with GET /credentials?api_id={api_id}

Optional sections (add via ?sections=):

  • tags — tag objects with names and descriptions
  • paths — full paths object (can be very large — prefer GET /apis/{api_id}/operations)
  • components — all reusable component definitions (schemas, parameters, responses, etc.)
  • webhooks — OpenAPI 3.1 webhooks (if present)

Full spec download: GET /apis/{api_id}/openapi.json

get/apis/{api_id}

Path parameters

api_idstring required

API ID (hostname or hostname/path format)

API ID (hostname or hostname/path format)

Query parameters

sectionsstring nullable

Comma-separated list of OpenAPI spec sections to include in the response. Valid values: components, info, paths, security, servers, tags, webhooks. Default (when omitted): info, security, servers. Large sections (paths, components, webhooks) must be requested explicitly. Use GET /apis/{api_id}/openapi.json to download the full merged spec.

Comma-separated list of OpenAPI spec sections to include in the response. Valid values: components, info, paths, security, servers, tags, webhooks. Default (when omitted): info, security, servers. Large sections (paths, components, webhooks) must be requested explicitly. Use GET /apis/{api_id}/openapi.json to download the full merged spec.

Response

API detail — format controlled by Accept header.

idstring required

API ID (typically the base domain)

namestring nullable

Human-readable API name from spec info.title

vendorstring nullable

API vendor or maintainer organization

descriptionstring nullable

API description from spec info.description

base_urlstring nullable

Primary base URL from spec servers array

created_atnumber nullable

Unix timestamp when API was imported

Example response

{
  "id": "api.github.com",
  "name": "GitHub REST API",
  "vendor": "GitHub",
  "description": "GitHub's REST API for managing repositories, issues, and pull requests",
  "base_url": "https://api.github.com",
  "created_at": 1672531200
}

Changes