Common API Properties
The most widely used properties across API operations — identified, described, and made machine-readable so they can be used to automate and standardize the API ecosystem. These properties work directly with APIs.json indexes.
Agent Prompt
A prompt designed for autonomous agents — instructions, context, and guardrails for driving the API as a tool inside an agentic workflow.
View
Agent Skills
A set of agent skills (e.g. Claude Skills) packaging instructions and tools so an AI agent can use the API competently.
View
Alerts Twitter Handle
A dedicated Twitter/X handle that posts status and incident alerts for the API.
View
ALPS
An Application-Level Profile Semantics document describing the semantics of an API's data and affordances independent of any single media type or protocol.
View
API Blueprint
An API Blueprint document — a Markdown-based API description format. Human-friendly and still used by some documentation and mock toolchains.
View
API Examples
Machine-readable request/response examples for the API's operations, useful for docs, mocks, and tests.
View
Index
A discoverable catalog of APIs, packages, or related resources published by a provider — a single document that lists what exists and where to find it. The index is the entry point for both humans browsing an offering and machines crawling an ecosystem; it is what makes an API portfolio (rather than a single API) navigable.
View
API Reference
The endpoint-by-endpoint reference documentation — every operation, parameter, and response, usually generated from the API definition.
View
Arazzo
An OpenAPI Arazzo description — a deterministic, multi-step workflow that chains API calls into a complete job-to-be-done. Where OpenAPI describes operations, Arazzo describes the sequence.
View
AsyncAPI
The AsyncAPI description for an event-driven or streaming API — channels, messages, and bindings for Kafka, MQTT, WebSockets, and other async protocols. The event-driven counterpart to OpenAPI.
View
Authentication
Authentication is essential for most public APIs and is often the most common point of friction when it comes to onboarding with an API. This API Commons property is often a human-readable affair, and will need to become something that is machine-readable if we are going to scale things.
View
Backstage API
A Backstage catalog entity (API kind) describing the API for an internal developer portal built on Spotify's Backstage.
View
Blog Feed
A machine-readable RSS/Atom feed of the blog, so updates can be tracked programmatically.
View
Blog
A blog is an essential communication tool for any API operation, providing a simple self-service way for API producers to keep their consumers up to date on any changes. An active blog is a quick way to get up to speed on what an API does and can easily be syndicated via RSS or Atom feeds, and can be used to broadcast to social media.
View
Bruno Collection
A Bruno collection — a Git-friendly, file-based set of API requests for the open-source Bruno client.
View
Careers
The provider's careers or jobs page — useful signal on the team and investment behind the API.
View
Change Log
Communicating change is important for any API provider, and having a simple and up-to-date log of what has changed is a great way to make change self-service. Your change log doesn't have to be verbose, but should be accurate and provide as much useful detail for consumers as possible.
View
Chargeback Policy
A ChargebackPolicy property references a document describing how an API provider or internal platform allocates and recovers costs across teams, cost centers, or business units — including chargeback (actual cost transfer) and showback (visibility without transfer) methodologies. Chargeback and invoicing are formal capabilities in the FinOps Framework. Publishing a chargeback policy makes internal billing transparency discoverable, especially important for platform APIs used across multiple organizational units.
View
Compare
A comparison artifact or diff between two versions of an API definition, surfacing what changed between releases.
View
Compliance
Compliance attestations and certifications (SOC 2, ISO, HIPAA, GDPR) relevant to the API.
View
Console
An interactive web UI for managing API access — issuing and rotating credentials, scoping projects, enabling features, and inspecting usage and billing. The console is the operational surface of an API, distinct from the developer portal (informational) and the marketing website (promotional). For cloud-style providers the console is often the dominant consumer surface and the primary trust boundary.
View
Contact
API providers should be afraid to make contact information to consumers, making it easy to access a contact form, email address, or other way to contact. Contact information is often replace with forums and other self-service way to engage with a community, but nothing replaces a form or email.
View
Data Contract
A data contract describing the schema, semantics, quality guarantees, and SLAs for a data product exchanged between producer and consumer.
View
Deprecation Policy
Every API will eventually be deprecated, so having a plan and communicating the deprecation policy with consumers via a dedicated page makes a lot of sense. This page will help API providers think a little bit about the future, and establish some guard rails and channels for communication with consumers.
View
Documentation
A reference to the human readable documentation for an API, that describes the surface area of an API with all the details consumers need. This documentation may or may not be generated from an OpenAPI or other machine-readable artifact, but is published as HTML or Markdown, and mean for human consumption when onboarding with an API.
View
Error Codes
Providing a detailed list of error codes that API consumers can expect when integrating with an API, sharing common HTTP status codes, but also custom errors returned. Having a single page helps communicate errors with consumers, but it also helps producers evaluate how errors are handled across many different APIs.
View
Evolution
A description of how an API or schema evolves over time — versioning rules, compatibility guarantees, and the change policy consumers can rely on.
View
Examples
Worked examples showing the API in use — payloads, snippets, and end-to-end scenarios.
View
FAQ
A curated set of questions consumers actually ask, with concise authoritative answers. A good FAQ short-circuits the common-question slice of support load, makes the API feel approachable, and surfaces issues the rest of the documentation does not address head-on. FAQs work best when they are sourced from real support conversations and revised on a cadence rather than written once and abandoned.
View
Features
A summary of what an API can do — the consumer-facing capability list that bridges marketing claims and reference documentation. Features pages are how prospective consumers evaluate fit before they read the reference, and how internal teams confirm parity with competitors. A clear features pointer lets discovery tools surface capability summaries without crawling the entire docs site.
View
FinOps Framework
A document describing how the provider aligns to the FinOps Foundation Framework — which capabilities they support and at what maturity.
View
FinOps
The financial-operations artifact for the API — how consumption is metered, allocated, and billed so consumers can reason about cost. The most widely used FinOps property in the wild.
View
FOCUS Billing Export
A billing export conforming to the FinOps Open Cost & Usage Specification (FOCUS), giving consumers a standardized view of cost and usage.
View
FOCUS Conformance Report
A report attesting how the provider's billing data conforms to the FOCUS specification.
View
FOCUS Contract Commitments
FOCUS-aligned data describing contractual commitments and discounts affecting cost.
View
Forums
Forums are a common way for developers to engage in a self-service way within a community. The forum may or may not be owned and managed by a platform, but almost always thrive when they are user supported, providing an opportunity for more advanced API consumers to answer questions and support the needs of newer API consumers.
View
Getting Started
Providing the basic steps of how an API consumer can get started using an API with as few steps as possible is essential for any API. Like other common properties, a getting started isn't just for API consumers to understand how to onboard, and it is about pushing API producers to simply and reduce friction when it comes to onboarding.
View
GHG Protocol Report
A greenhouse-gas report aligned to the GHG Protocol, covering the provider's emissions.
View
GitHub HTTP URL
The HTTPS clone URL for a GitHub repository, for tooling that clones the source.
View
Governance Rules
A broader API governance policy or ruleset spanning design, security, and lifecycle expectations across an organization's APIs.
View
GraphQL Schema
A GraphQL schema (SDL) defining the types, queries, mutations, and subscriptions a GraphQL API exposes — the contract a GraphQL client introspects and codegens against.
View
GraphQL
A reference to a provider's GraphQL endpoint, schema, or GraphQL developer surface — the query-language alternative to REST for fetching exactly the data a client needs.
View
Insomnia Collection
An Insomnia export — a runnable collection of requests and environments for the Insomnia API client.
View
Integrations
Providing ready to go integrations with other APIs has become commonplace as part of Software as a Service (SaaS) solutions, and help demonstrate the value an API provides. Demonstrating how an API can be used with the existing platforms that API consumers are already using help make your APIs more useful and sticky for developers.
View
Interface License
Using the API Commons interface license to provide a legal position of the naming, ordering, and overall design of your API, not just the code or other parts. An interface license will help define the legal tone you take with how your API paths are able to be put to work within other applications and integrations.
View
Invoice Reconciliation
Artifacts or guidance for reconciling provider invoices against measured usage.
View
JSON Forms
A JSON Forms definition that renders a data-entry UI from a JSON Schema, pairing structure with presentation for forms-driven API interaction.
View
JSON-LD Context
A JSON-LD @context file mapping a payload's terms to IRIs in a shared vocabulary — the dictionary that makes JSON-LD documents interoperable.
View
JSON-LD
A JSON-LD document adding linked-data semantics to JSON via a shared vocabulary, letting machines understand what fields mean across systems.
View
JSON Schema
A JSON Schema document describing the structure, types, and constraints of a JSON payload. Used standalone for validation and embedded inside OpenAPI and AsyncAPI definitions.
View
JSON Structure
A JSON Structure document — a schema approach focused on describing the shape and structure of JSON data for validation and codegen.
View
Lifecycle
Breaking down the stages of the lifecycle across APIs, while also providing instances for individual APIs, with details of each stage, the policies and rules applied within each stage, and the progress that APIs are making throughout the lifecycle
View
llms.txt
An llms.txt file — a curated, LLM-friendly map of a site's most useful content and docs, so AI tools can navigate the provider efficiently.
View
Login
Providing what is needed for existing API consumers to login and access their accounts, keys, and other information regarding their API consumption. A login allows any consumer of an API to be able to access the resources they will need to make a decision when it comes to integrating, expanding, or deprecating their usage of an API, providing what consumers will expect.
View
Mock MCP Server
A mock Model Context Protocol server that lets developers and agents exercise the API's MCP surface without hitting production.
View
Mock REST Server
A mock REST server generated from the API definition, providing realistic responses for development and testing before integrating the real API.
View
Model Context Protocol
A reference to the provider's MCP server or MCP integration, exposing the API to AI agents through the Model Context Protocol.
View
OpenAI Plugin Manifest
An ai-plugin.json manifest describing an API to an LLM tool/plugin runtime — name, description, and the OpenAPI it should call.
View
OpenAPI
The OpenAPI description for a REST API — the machine-readable contract that defines paths, operations, parameters, schemas, and responses. The most widely adopted API definition format, and the backbone of documentation, SDK, mock, and testing tooling.
View
OpenCost Allocation API
The OpenCost allocation API surface for querying cost allocation data programmatically.
View
OpenCost Specification
A reference to OpenCost — the CNCF specification for measuring and allocating cloud and Kubernetes cost.
View
Performance
Defining the benchmark for performance of an API, providing an overview of how performance is approached and what it means, while also providing actual tests, results, and other evidence that demonstrates that performance is taken seriously.
View
Plans
The access plans or tiers for the API, ideally machine-readable so limits and entitlements can be reasoned about programmatically.
View
Policies
Providing the machine-readable policies that define the business aspects of API operations and how it is governed, breaking down the business and technical details of API operations in terms that help organize and make the governance of APIs approachable by business stakeholders and leadership.
View
Portal
Providing references to the relevant portal to an APIs operation, providing access to the landing page for the wider company, operations, as well as just for individual APIs when it makes sense--helping connect the wider ecosystem surrounding each API being delivered.
View
Postman Collection
A Postman Collection — a runnable set of API requests, examples, and tests that consumers can import and execute immediately.
View
Postman Workspace
A public Postman Workspace bundling an API's collections, environments, and documentation in one shareable place.
View
Pricing
Providing a machine-readable scaffolding to define the plans and pricing for APIs, and the common elements of each tier of pricing and access available. Pricing is not just about the financial aspect of access to APIs, it is also about which APIs you will have access to, and how much of a resource you can consume over time. Pricing is about enabling API consumers to have a plan for how they will use digital resources that is in alignment with a platform business strategy.
View
Privacy Policy
Breaking up the privacy policy into machine-readable, schema defined properties that allow for the legal side of an API to be understood programmatically. A privacy policy sets the stage when it comes to consumption, helping consumers with what they can expect when it comes to how their data and usage of digital resources will be shared or sold.
View
Prompt Template
A parameterized prompt template with placeholders for inputs, so the same prompt pattern can be reused across requests and use cases.
View
Prompt
A reusable AI prompt that helps a human or agent accomplish a task against the API — a vetted, provider-blessed prompt rather than a guessed one.
View
Public APIs Listing
A listing of the provider's APIs in a public directory or catalog — a discovery breadcrumb back to the source.
View
RAML
A RESTful API Modeling Language definition — a YAML-based API design format emphasizing reuse and resource types. An OpenAPI alternative with a dedicated tooling lineage.
View
Rate Limits
All APIs should possess rate limits that govern the amount of any digital resource or capability a consumer be able to access, with well-communicated, consistent, and enforced rate limits. Rate limits are what give API producers control over their digital resources, and are a fundamental aspect of how any type of APIs is publicly made available.
View
Release Notes
A time-ordered, human-facing record of what shipped in each release — new features, deprecations, fixes, and migration guidance. Release notes are the consumer-facing companion to a change log; where a change log catalogs every commit-level change, release notes summarize the things consumers need to act on or celebrate. They are essential for any API with paying customers and for any team that wants to set explicit expectations about pace and stability.
View
Review
A published review or assessment of the API — for API Evangelist indexes, the API Evangelist review of the provider.
View
Road Map
Providing visibility as far into the future as possible is a common trait of successful APIs. Maintaining, publishing, and consistently communicating around a road map helps bring alignment between API producer and consumers, providing an essential building block for managing change across any platform.
View
Rules
Providing an index of the machine-readable rules available for governing APIs, offering rules for linting API operations, as well as the surface area of each API, helping standardize how APIs are design, but also delivered across teams within an enterprise.
View
Sandbox
An isolated environment that mirrors the production API but operates on non-real data, so consumers can integrate, test, and demo without financial, reputational, or compliance consequences. Sandboxes are essential for any API that moves money, sends messages, mutates real-world state, or is subject to per-call cost — and increasingly expected even for read-only APIs as a low-friction way to evaluate.
View
SCI Report
A Software Carbon Intensity report quantifying the carbon emissions associated with the service.
View
Security
The security of any API is important to producer and consumer, and no consumer should be using any 3rd party API platform that does not clearly communicate and demonstrate an API is secure. API security is a foundational business building block in any API ecosystem when it comes to building trust and keeping consumers integrated with an API.
View
Serverless Workflow
A CNCF Serverless Workflow definition describing an event-driven, stateful orchestration of services and functions.
View
Service Level Agreement
A service level agreement, or simply SLA, defines the level of service you expect from a vendor, laying out the metrics by which service is measured, as well as remedies or penalties should agreed-on service levels not be achieved. A SLA sets the tone between an API producer and consumer and can be communicated as part of API change management practices.
View
Services
The discrete services or products an API or platform exposes — a machine-readable breakdown of what's offered.
View
Sign Up
Where users can sign up for access to an API, providing what is needed to onboard in a manual or automated way, reducing friction in putting to work. Sign up or registration can utilize existing standards like OpenAPI or native solutions which help make it as easy as possible for consumers to manually or automatically sign up to use an API.
View
Software Carbon Intensity
A Software Carbon Intensity (SCI) measure for the API/service, per the Green Software Foundation specification.
View
Software Development Kits (SDKs)
Providing code snippets, libraries, and full software development kits, or simply SDKs is considered standard operating procedure for APIs. Generating SDKs from OpenAPI has become common, and providing all of the top programming languages is expected by developers, making SDKs one of the essential API building block for any API operations.
View
Specification
A pointer to the API's governing specification or standard document when it isn't one of the named contract formats.
View
Spectral Rules
A Spectral ruleset that governs how an API's OpenAPI or AsyncAPI definition is linted — publishing it makes the provider's design and governance standards discoverable and lets consumers see the quality bar the API is held to.
View
Status Page
A status page provides API consumers with real-time information regarding the up-time and availability of each API being made available. Status pages often provide current as well as historical information regarding stability or outages, helping build trust with consumers over time regarding the health of an API platform.
View
Summary
A concise summary of the API or provider — what it does and who it's for, in a paragraph.
View
Support
Offering a standardized set of API support for consumers to tap into helps ensure that onboarding is as frictionless as possible while helping build trust with consumers. Support can be as simple as email, or as structured as a ticketing system, but whatever is offered, it should work to keep API consumers taken care of throughout their journey.
View
Swagger
A Swagger 2.0 definition — the predecessor to OpenAPI 3.x. Still published by many providers and consumed by a long tail of tooling; treat as an older OpenAPI dialect.
View
Tagging Policy
A TaggingPolicy property references a document defining the cost allocation tag taxonomy for an API or platform — including required tag keys such as CostCenter, Environment, Product, and Owner, along with allowed values and compliance requirements. Cost allocation tagging is a foundational FinOps practice, and the FinOps Foundation publishes guidance on tagging policy compliance. Publishing a tagging policy makes cost attribution requirements discoverable by consumers integrating the API into their FinOps workflows.
View
Terms Of Service
Breaking up the terms of service into machine-readable, schema defined properties that allow for the legal side of an API to be understood programmatically. Providing a break down of what the legal constraints involved with putting an API to use will help consumers understand if it is a fit for their business needs.
View
Tools
Developer tools the provider offers around the API — explorers, generators, validators, and utilities.
View
Tutorials
Step-by-step learning content that walks a consumer from zero to a working integration around a specific use case. Tutorials sit between the bare quickstart (one-call hello world) and the full reference (everything you could call); their job is to teach how the pieces compose. A healthy tutorials surface covers the canonical workflows for the API and is the second-most-visited area of a portal after the reference.
View
Unit Economics
A UnitEconomics property references a document describing the per-unit cost model for an API — such as cost per API call, cost per gigabyte processed, cost per token consumed, or cost per transaction. Unit economics are a core FinOps capability under the Quantify Business Value domain. Publishing a unit cost breakdown alongside an API makes pricing structure discoverable by enterprise procurement, FinOps tools, and developers building cost-aware applications.
View
Use Cases
Providing the who, what, how, and why of an API, establishing details about who the intended consumer is, while also linking use cases to specific operations to help align the business and technical details of an API.
View
Versioning
The details of how an API is being versioned with information about how change is being communicated with consumers across multiple channels. Having a formal approach to versioning published and communicated helps lay the ground work for change, but also keeps API consumers aligned with what has changed.
View
Vocabulary
A controlled vocabulary or term set that an API's data references — the shared dictionary of codes, enums, and concepts that gives fields consistent meaning.
View
WADL
A Web Application Description Language document — an early XML format for describing HTTP/REST resources. Rare today but still encountered in legacy catalogs.
View
Webhooks
The webhooks the API emits — events, payloads, and how to subscribe — turning the API push-capable.
View
Website
The primary public website for the company or product behind an API — distinct from the developer portal. The website is where the broader audience (buyers, partners, press, candidates) lands; it usually links downstream into the developer portal, documentation, signup, and pricing. Standardizing a pointer to the website lets discovery tools tie an API back to its parent organization without scraping.
View
Workflow
A generic multi-step API workflow definition that sequences operations across one or more APIs to accomplish an outcome.
View
WSDL
A Web Services Description Language document defining a SOAP web service's operations, messages, and bindings. The contract format for the SOAP/XML generation of APIs.
View