APIs.json Properties
These are the property types we encourage API producers to include in their APIs.json indexes. They are based on the common building blocks of leading API providers and represent what API consumers have come to expect. Many of these properties are defined in detail at API Commons.
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
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
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 that describes how an API provider or internal platform allocates and recovers costs across teams, cost centers, or business units — including both chargeback (actual cost transfer) and showback (visibility without transfer) methodologies. Chargeback and invoicing are formal capabilities in the FinOps Framework. Publishing a chargeback policy alongside an API makes internal billing transparency discoverable, which is especially important for platform APIs used across multiple organizational units.
View
CLI
A CLI property references the command-line interface tool published by the API provider for interacting with the API from a terminal. CLIs are increasingly a first-class part of API developer experience — they make automation, scripting, and CI/CD integration straightforward without requiring SDK knowledge. Indexing the CLI means tooling can surface it alongside SDKs as an integration option.
View
Community
A Community property references the primary community hub for the API — whether that is a forum, Discord server, Slack workspace, developer community site, or other gathering place. Community is one of the most powerful signals of API health and longevity. Indexing the community presence makes it findable by developers who want to engage beyond the documentation, and by governance tools that check for an active support ecosystem.
View
Compliance
A Compliance property references documentation or certification materials that describe how the API meets regulatory, industry, or organizational compliance requirements — such as SOC 2, GDPR, HIPAA, PCI-DSS, or internal data governance standards. Enterprise API consumers increasingly need to verify compliance posture before integrating. Indexing compliance materials alongside the API makes this due diligence straightforward.
View
Console
A Console property references the interactive API explorer embedded in the developer portal — the try-it-now interface where developers can make live API calls from the browser without writing code. Consoles lower the barrier to first API call and are one of the most effective onboarding tools an API provider can offer. Indexing the console URL makes it findable by tools that help developers explore capabilities.
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
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
Developer Portal
A Developer Portal property references the dedicated technical hub where developers find API documentation, authentication guides, SDK downloads, sandbox access, and support resources. It is the primary destination for API integration work and is distinct from the general corporate website. Indexing the developer portal URL enables discovery tools to surface the right starting point for technical consumers.
View
Discord
A Discord property references the Discord server where the API provider engages with its developer community. Discord has grown into a primary community platform for developer tools and APIs — it offers persistent channels, real-time chat, voice, and role-based organization. Indexing the Discord server makes it discoverable as a support and community resource alongside forums, Stack Overflow tags, and other community properties.
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
Examples
An Examples property references human-readable code samples, use-case walkthroughs, or recipe guides that show how to use the API in practice. These are distinct from machine-readable ApiExamples objects embedded in a spec — Examples links out to a documentation resource where developers can learn by seeing the API in action across common scenarios.
View
FAQ
An FAQ property references the frequently asked questions resource for the API — a curated set of questions and answers that address the most common confusion points, integration challenges, and edge cases developers encounter. FAQs complement reference documentation by surfacing practical knowledge that is hard to express in a spec but essential for productive integration.
View
FinOps Framework
A FinOpsFramework property references a document describing how an API provider or platform aligns to the FinOps Framework — the operational and cultural framework published by the FinOps Foundation for managing cloud, SaaS, and AI financial operations. The 2025 Framework revision expanded coverage to four scopes: public cloud, SaaS, data center, and AI. A FinOps Framework alignment document describes which capabilities the provider supports, at what maturity level, and how they enable customer FinOps practices such as cost allocation, budgeting, forecasting, and unit economics.
View
FOCUS Billing Export
A FocusBillingExport property references an endpoint or documentation for a billing data export that conforms to the FOCUS (FinOps Open Cost and Usage Specification) schema. FOCUS is the cross-vendor open standard maintained by the FinOps Foundation for normalizing cloud, SaaS, and PaaS billing data. A FOCUS-conformant billing export allows API consumers, enterprise buyers, and FinOps tools to ingest cost and usage data in a consistent, vendor-neutral format without custom transformation.
View
FOCUS Conformance Report
A FocusConformanceReport property references a published document that describes how a provider's billing data maps to the FOCUS (FinOps Open Cost and Usage Specification) schema — including any gaps between native fields and the FOCUS column definitions. The FinOps Foundation's certified conformance program requires providers to publish a native-to-FOCUS column mapping and a conformance gap report. Linking this document from an APIs.json index makes verifiable billing data compatibility discoverable by FinOps tools and enterprise procurement teams.
View
FOCUS Contract Commitments
A FocusContractCommitments property references an endpoint or document for commitment-based pricing data structured according to the FOCUS Contract Commitment Dataset, introduced in FOCUS v1.3. This supplemental dataset isolates reserved instance, savings plan, and enterprise discount program terms — including commitment start and end dates, remaining committed units, and commitment type — from per-row cost and usage data. It enables FinOps tooling to reconcile commitment purchases against actual consumption without parsing billing rows.
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 GHGProtocolReport property references a published greenhouse gas emissions report for an API provider or platform, structured according to the GHG Protocol — the global standard for measuring and managing Scope 1, 2, and 3 greenhouse gas emissions. Cloud provider carbon APIs (AWS Sustainability Console, Azure Emissions Impact Dashboard, GCP Carbon Footprint) all align to GHG Protocol categories. Linking a GHG Protocol report from an APIs.json index makes the provider's emissions posture discoverable by enterprise customers with Scope 3 supply chain reporting requirements.
View
GitHub Organization
A GitHub Organization is commonplace for larger more organized API producers, establishing a place where you can find SDKs and other code used for integration, but also machine-readable artifacts, issues, discussions, and other useful outputs from everyday API operations that will help provide nutrients for an API ecosystem.
View
GitHub Repository
GitHub repositories are great for making SDK and other artifacts developers will need to put an API to work, but you can also publish OpenAPI, examples, and even run your entire API portal using GitHub pages. A GitHub repository has proven itself to be an essential building block of any public API program, and powers API Commons.
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
An InvoiceReconciliation property references documentation that explains how an API provider's billing data maps to issued invoices — including how to match billing export rows to invoice line items using invoice identifiers. FOCUS 1.2 introduced dedicated Invoice ID columns specifically to enable this reconciliation. For enterprise API consumers, the ability to tie API usage records to financial invoices is a compliance and audit requirement. Linking reconciliation documentation from an APIs.json index makes this mapping discoverable alongside the API itself.
View
JSON-LD
A JSONLD property references a JSON-LD context document that provides structured, linked-data semantics for the API's data. JSON-LD makes it possible for machines to interpret the meaning of API responses by linking terms to a shared vocabulary. This is particularly valuable for APIs that participate in knowledge graph workflows or need to interoperate with semantic web tooling.
View
License
A License property references the software license that governs the use of the API's SDKs, client libraries, or code samples. This is distinct from the InterfaceLicense (which covers the API interface itself) and TermsOfService (which covers API usage rights). For open source SDK users in particular, knowing the code license up front is essential for compliance with organizational open source policies.
View
LinkedIn
A LinkedIn property references the API provider's LinkedIn company page or showcase page. LinkedIn is increasingly used by API teams for product announcements, developer advocacy content, and job postings. For enterprise API consumers evaluating providers for long-term integration, the LinkedIn presence provides organizational context that complements the technical documentation.
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
Naftiko Capability
A NaftikoCapability property references a Naftiko capability YAML specification — a single declarative file that defines what APIs are consumed upstream, what surfaces are exposed (REST, MCP, Agent Skills), and what governance, identity, and telemetry rules apply. Capability specs are the deployable unit of the Naftiko platform: each one is validated by JSON Schema, committed to Git, and serves as both the implementation artifact and the governance contract. Publishing a capability spec makes it possible for AI agents, orchestration tools, and developer portals to discover and invoke governed API capabilities without direct knowledge of the underlying provider APIs.
View
Naftiko Fleet
A NaftikoFleet property references a Naftiko fleet catalog — a configuration that registers and manages a collection of capability specs as a governed, runtime-deployed fleet. A fleet provides the execution environment for capabilities: it handles routing, identity propagation, observability, and multi-protocol exposure across REST, MCP, and Agent Skills surfaces. Publishing a fleet link makes a provider's complete capability surface discoverable and executable by AI agents and orchestration platforms.
View
OpenCost Allocation API
An OpenCostAllocationAPI property references an API endpoint that exposes Kubernetes and cloud infrastructure cost allocation data in a format compatible with the OpenCost Allocation API specification. The OpenCost API returns workload cost data aggregated by namespace, deployment, pod, service, or label, and supports time-window queries and shared cost distribution. Indexing an OpenCost-compatible allocation endpoint makes container cost data programmatically accessible to FinOps dashboards, chargeback tools, and engineering teams.
View
OpenCost Specification
An OpenCostSpecification property references documentation describing how an API or platform's cost reporting conforms to the OpenCost Specification — a CNCF Incubating project that defines a vendor-neutral standard for measuring and allocating Kubernetes and cloud infrastructure costs. OpenCost covers cluster asset costs (nodes, storage, load balancers, network egress), workload cost allocation by namespace, deployment, pod, and label, and idle resource cost distribution. Linking an OpenCost conformance document makes Kubernetes cost data interoperable with FinOps tooling.
View
Portal
A Portal property references the top-level entry point for API consumers — the landing page where developers go to discover capabilities, find documentation, and begin onboarding. Not all API providers distinguish between their portal and their developer portal; both types are supported so providers can be precise about which kind of entry point they are linking.
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
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 ReleaseNotes property references the versioned narrative account of what changed in each API release — what was added, what was fixed, and what developers need to know to upgrade. Release notes are distinct from a change log in that they are typically written for a human audience, focused on a specific version, and explain the why behind changes. Both are valuable for API consumers maintaining long-lived integrations.
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
Sandbox
A Sandbox property references the safe testing environment where developers can experiment with the API using non-production data and without affecting live systems. Sandboxes are critical for reducing the time to first working integration and for letting developers validate their implementation before going live. Indexing the sandbox URL makes it discoverable as a distinct onboarding resource separate from production endpoints.
View
SCI Report
An SCIReport property references a published carbon intensity report for an API or service calculated using the Software Carbon Intensity (SCI) specification — an ISO-ratified standard from the Green Software Foundation. An SCI report documents the measured or estimated carbon intensity for a specific version or deployment of the API, including the methodology, data sources, energy and embodied carbon inputs, the chosen functional unit, and the resulting score. Regular SCI reports enable tracking of carbon efficiency improvements over time.
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
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
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
Slack
A Slack property references the Slack workspace or channel where the API provider communicates with developers. Slack has become a standard community channel for developer-facing APIs, offering real-time Q&A, announcements, and direct access to the API team. Indexing the Slack community alongside other support resources ensures that developers can find real-time help through the channel they already use.
View
Software Carbon Intensity
A SoftwareCarbonIntensity property references a published Software Carbon Intensity (SCI) score or methodology document for an API or service. SCI is an ISO-ratified standard developed by the Green Software Foundation that quantifies the carbon intensity of software using the formula SCI = ((E * I) + M) per R — where E is energy consumed, I is the marginal carbon intensity of electricity, M is embodied carbon, and R is a functional unit such as per API call or per user. Publishing an SCI score makes carbon efficiency measurable and comparable across API providers.
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
Spectral Rules
A SpectralRules property references the Spectral ruleset file that governs how the API's OpenAPI or AsyncAPI spec is validated. Publishing this alongside the spec makes governance rules discoverable and enables consumers to understand the quality standards the API is held to. It also supports meta-governance workflows — checking whether a provider has published their own API design rules.
View
Stack Overflow
A StackOverflow property references the Stack Overflow tag or question collection associated with the API. Stack Overflow is where many developers search for answers to specific integration problems, and an active tag is a signal of a healthy developer community. Indexing the Stack Overflow presence alongside official documentation gives consumers a complete picture of where to find help.
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
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
Tagging Policy
A TaggingPolicy property references a document that defines 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 working group guidance on tagging policy compliance. Publishing a tagging policy alongside an API makes cost attribution requirements discoverable by consumers who need to integrate the API into their own 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
Training
A Training property references structured learning resources for the API — courses, tutorials, certification programs, or guided learning paths. Training resources are designed to take a developer from unfamiliar to productive in a structured sequence, and are distinct from reference documentation. Indexing training materials alongside technical artifacts makes the full learning path discoverable.
View
Unit Economics
A UnitEconomics property references a document that describes 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 defined in the FinOps Framework under the Quantify Business Value domain. Publishing a machine-readable or human-readable unit cost breakdown alongside an API makes pricing structure discoverable by enterprise procurement, FinOps tools, and developers building cost-aware applications.
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 Vocabulary property references a published data model or semantic vocabulary that defines the terms, types, and relationships used in the API. This can be a JSON-LD context, an OWL ontology, or a plain-language glossary. Publishing a vocabulary makes API semantics explicit and machine-interpretable, which is increasingly important for AI agents that need to reason about what an API's data means.
View
Webhooks
Webhooks are a way to communicate between applications by sending data to another application when an event occurs. Webhooks are HTTP-based callback functions that are automated and triggered by an event in a source system, then sent to a destination system, providing event-driven capabilities utilizing simple HTTP "reverse APIs".
View
Website
A website property references the primary marketing or corporate web presence for an API provider. It is distinct from the developer portal — the website is the top-level entry point for the organization, while the developer portal is where technical consumers go to integrate. Linking both helps discovery tools surface the full organizational context around an API.
View
X
An X property references the API provider's account on X (formerly Twitter). X is used by many API teams for real-time announcements, status updates, developer advocacy, and community engagement. The X type is the current canonical name for this platform; the Twitter type remains supported for backward compatibility. Indexing the X account makes the provider's social presence findable alongside their other operational properties.
View
YouTube
A YouTube property references the API provider's YouTube channel or playlist where video content about the API lives — tutorials, conference talks, demo walkthroughs, and feature announcements. Video has become a primary onboarding medium for many developers. Indexing a YouTube channel makes video content discoverable alongside written documentation and enables tools to surface it as a learning resource.
View