V2 capability registry

/api/v2/capabilities

AUTHENTICATIONNone · publicAUTHORITATIVE OWNERapi-gatewayCONTRACT AUTHORITYGenerated Rust OpenAPISTATUSSource ready · production listed

PURPOSE + BUSINESS CONTEXT

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

WHEN THIS CALL IS USEFUL

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.

MACHINE CONTRACT

The exact deployed parameters, schemas, responses, security requirements, and Hybrid-Chain agent metadata are authoritative at this operation's production OpenAPI JSON Pointer. The readable tables below add integration guidance; the deployed OpenAPI controls if guidance and the machine contract ever differ.

Open the authoritative production contract ↗

EXTENDED INTEGRATION GUIDANCE

Readable request and response reference

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.

DOCUMENTATION STATUS

This route is implemented in canonical gateway source and appears in the production OpenAPI snapshot observed 2026-09-11T06:35:11.572Z. Authentication, tenant, feature, venue, and market policy still apply.

Verify the exact production OpenAPI operation ↗Return to the V2 directory ↗