Skip to main content

Methods your team can run, inspect, and disagree with.

These field guides turn standards and product boundaries into workflows a platform, DevEx, API product, or documentation team can test. Each one answers early, shows the work, names failure modes, and records its review date.

Start with the decision blocking your release.

The collection is intentionally small. A page enters this library only when it has a distinct search intent, an accountable owner, an explicit technical review scope, primary-source support, a useful artifact or checklist, and descriptive links back to the product surface where the method applies.

  • 01

    API Delivery vs API Management: Where Each Fits in the API Lifecycle

    API management governs runtime traffic and policy. API delivery turns a contract into docs, SDKs, examples, and agent tools. Learn where each belongs.

    Accountable owner: Aria Shishegaran. Tested ; refresh due .

    Read the guide
  • 02

    Docs as Code: A Workflow That Prevents API Drift

    Use this docs-as-code workflow to review prose, OpenAPI, examples, generated reference, and release evidence together without creating a second source of truth.

    Accountable owner: Aria Shishegaran. Tested ; refresh due .

    Read the guide
  • 03

    OpenAPI to MCP: Build Safe, Useful Agent Tools

    A practical OpenAPI-to-MCP workflow for operation selection, tool schemas, descriptions, authorization, side effects, testing, and release verification.

    Accountable owner: Aria Shishegaran. Tested ; refresh due .

    Read the guide
  • 04

    API Documentation Examples: A Practical Evaluation

    Evaluate API documentation examples with a first-call rubric covering orientation, authentication, requests, responses, errors, operations, and change safety.

    Accountable owner: Aria Shishegaran. Tested ; refresh due .

    Read the guide

Evidence before volume.

We do not publish a keyword page merely because demand exists. Product claims must match shipped behavior, standards claims link to primary sources, and examples must lead to an action a reader can reproduce. Unsupported or roadmap capabilities are labeled at the point where they matter.

Browse the broader resource directoryfor product routes and future tools, or start with the platform overviewwhen the buying decision is already clear.

Apply the method to your next release.

Start with the surface your team owns now, then connect it to the rest of the release when the evidence is ready.

Become a Design Partner