GET

Platform metadata

V2 capability registry

/api/v2/capabilities

AUTHENTICATIONNone · publicService ownerapi-gatewayContract sourceOpenAPISTATUSProduction listed

Purpose and usage

What this endpoint does

Return the machine-readable capability registry that maps V2 operations to implementation status, owning domains, business modules, legacy parity, and agent integration context.

When to use it

Call this after ingesting OpenAPI to understand which operations are implemented, which domain owns them, how they map to business workflows, and which planned contracts are not executable.

OUTCOME · Discover

What changes

Read-only projection; it grants no mutation, settlement, traffic, or authority change.

WHY IT MATTERS

Gives people and agents a contract-backed way to discover v2 capability registry.
Gives human and agentic integrations one discoverable path from service identity and reference data to executable OpenAPI, capability ownership, guides, SDK status, and request-signing controls.

ISOLATION + AUTHORITY

Public service metadata, the OpenAPI document, the capability registry, guides, SDK listings, bearer credentials, step-up grants, and request-signing keys are separate artifacts. Discovery metadata grants no tenant, wallet, custody, payment, settlement, publisher, matching, or trading authority; public signing-key metadata never includes private key material.

BEFORE YOU CALL

No bearer credential is required; apply bounded filters and canonical public identifiers where the contract provides them.
Use the live OpenAPI schema as the authority for the exact request shape and response model.
Resolve whether the caller needs public discovery, bearer authorization, purpose-bound step-up, or RFC 9421 request signing; do not substitute one mechanism for another.

WHAT TO DO NEXT

Filter for implemented contracts before offering an executable action; keep planned entries visible only as non-executable roadmap context.
Follow the owning module and source references for the selected capability, then use OpenAPI for its exact request and response contract.

AGENT GUIDANCE

Use v2 capability registry only for the purpose and lifecycle stage described by this operation; do not treat it as authority for an adjacent action.
Use the live OpenAPI schema as the authority for the exact request shape and response model.
Treat deployment identity, OpenAPI schema, capability readiness, guide narrative, SDK publication, bearer authorization, step-up authorization, and request-signing proof as distinct inputs; none substitutes for another.
Use response links and canonical identifiers instead of constructing internal service URLs or scraping the website.

Contract reference

Use the deployed OpenAPI for exact parameters, schemas and security requirements. The tables below provide integration guidance.

Open this operation in OpenAPI

Request and response

Make the request

Examples illustrate integration intent; the referenced OpenAPI operation and component schemas define the executable shape.

PARAMETERS

Headers, path, query, and body

NAMELOCATIONPRESENCETYPE / RULES / PURPOSE

RESPONSES

Status and payload examples

200Complete implemented and planned operation registry with owners, applications, parity, request-shape authority, and business context.Read completed · JSON RESPONSE+

{
  "schemaVersion": 2,
  "summary": {
    "canonicalPublicOperations": 832,
    "implementedContracts": 470,
    "applications": 44
  },
  "applications": [
    {
      "name": "Developer Portal",
      "implementedContracts": 2,
      "plannedContracts": 0
    }
  ],
  "operations": [
    {
      "id": "developers-get-portal-catalog",
      "method": "GET",
      "path": "/api/v2/developer-portal",
      "status": "implemented-contract",
      "contract": {
        "authority": "openapi",
        "reference": "/api/v2/openapi.json#/paths/~1api~1v2~1developer-portal/get"
      }
    }
  ]
}

INTEGRATION DECISION

CALLER ACTION: Accept the returned representation or receipt, then filter for implemented contracts before offering an executable action; keep planned entries visible only as non-executable roadmap context.
RETRY SAFETY: Repeat only when the integration needs a fresher authoritative projection.
STATE RECONCILIATION: Use returned identifiers and versions as the comparison point for later reads. Refresh the application, credential or callback record; compare scope, key identifier, secret-display state, version, and revocation or rotation receipt.

OPERATIONAL NOTES

Security and lifecycle guarantees

Use this broader registry for application mapping, owner discovery, legacy parity, business context, and roadmap analysis—not as a substitute for live OpenAPI.
Never call a planned-contract. For implemented-contract entries, follow contract.reference to the exact OpenAPI JSON Pointer before generating a request.
documentationStatus, requestShapeAuthority, and exampleDisclaimer identify how much planning detail exists; even a fully profiled planned contract remains non-executable.
No bearer, query parameters, or request body are accepted. Registry counts and plans do not grant runtime access or predict deployment dates.

Reference version and availability details

This route is implemented in canonical gateway source and appears in the production OpenAPI snapshot observed 2026-10-02T23:27:55.510Z. Authentication, tenant, feature, venue, and market policy still apply.

Verify the exact production OpenAPI operation Return to the V2 directory