Zum Hauptinhalt springen

API and Reference

Use this page when you already know you need exact technical detail and want the fastest path to the right route family, product reference page, or provenance surface.

When to use this page​

  • You need exact routes, payload families, or control-plane surface categories.
  • You need to distinguish generated reference from conceptual or task-oriented guidance.
  • You need a public-safe explanation of where technical truth comes from and how to verify it.

Prerequisites​

  • You know whether your question is about docs publication, contracts, runtime readiness, event modeling, or a specific product.
  • You understand that exact payload details belong in owner-backed product reference pages when available.

What belongs here​

  • exact API route families and reference maps
  • generated or contract-backed technical surfaces
  • provenance-aware links to versioned product reference pages
  • guidance on how to verify that a reference claim is still current

Architecture / Flow​

Step-by-step procedure​

1. Choose the right reference depth first​

Use:

  • API Surface Map for a fast route-family overview
  • versioned product pages under /products/<tool>/<channel>/api-reference for tool-specific exact detail
  • Docs Provenance Model when the question is whether a reference page is current

Common high-value families:

GET /api/v1/docs/platform
GET /api/v1/contracts/registry
GET /api/v1/platform/projection-catalog
GET /api/v1/event-modeling/catalog
GET /api/v1/agent/contracts
GET /api/v1/observability/readiness

3. Prefer owner-backed product reference when exact payload shape matters​

For example, use:

  • API Reference
  • product-level stable or latest reference pages when they exist

4. Verify provenance before making a strong claim​

Reference truth should be checked against:

Current coverage posture​

  • public docs family coverage exists across the current tracked product set
  • some exact reference depth still depends on admitted canonical source files per product
  • reviewed publication and generated metadata remain part of the trust model

Verification​

This page is being used correctly when:

  1. the question is mapped to the right route family or product
  2. exact reference and conceptual guidance are not confused
  3. provenance or reviewed-publication checks are part of the answer when freshness matters

Common failure modes​

Using a guide page when exact reference is needed​

Problem:

  • the answer is directionally right but too vague to implement or verify.

Better path:

  • switch to the product or route-family reference page

Treating a reference page as self-proving​

Problem:

  • stale publication risk is ignored.

Better path:

  • pair exact reference with provenance and reviewed-publication checks

Source Truth​

Next paths​