APIs.json 0.21 introduces a new category of property types: financial operations and sustainability. As API consumption at enterprise scale has matured, two things have become clear. First, organizations need machine-readable links to billing, cost allocation, and pricing transparency artifacts — not just a generic Pricing URL. Second, as sustainability reporting requirements expand, API providers need a standard way to surface carbon intensity and emissions data alongside their technical artifacts.
Version 0.21 adds thirteen new reserved types across three areas: FOCUS billing standards, FinOps practice documents, and sustainability certifications.
FOCUS Billing Standards
The FOCUS (FinOps Open Cost and Usage Specification) is the cross-vendor open standard for billing data, maintained by the FinOps Foundation and now at version 1.3. It defines a normalized schema for cost and usage data across cloud, SaaS, and PaaS providers, enabling FinOps tools to ingest billing data without custom transformation per provider.
Three new types cover the FOCUS artifact surface:
- FocusBillingExport — links to an endpoint or documentation for a FOCUS-conformant billing data export. This is the primary artifact: the actual cost and usage data in normalized form.
- FocusConformanceReport — links to a published conformance gap report describing how the provider's native billing fields map to FOCUS columns. The FinOps Foundation's certification program requires this document.
- FocusContractCommitments — links to commitment-based pricing data structured according to the FOCUS Contract Commitment Dataset (introduced in FOCUS v1.3), which covers reserved instances, savings plans, and enterprise discount program terms separately from per-row usage data.
OpenCost
OpenCost is a CNCF Incubating project that defines a vendor-neutral specification for measuring and allocating Kubernetes and cloud infrastructure costs — covering node costs, persistent volumes, load balancers, network egress, and workload allocation by namespace, deployment, pod, and label.
- OpenCostSpecification — links to documentation describing how an API or platform's cost reporting conforms to the OpenCost Specification.
- OpenCostAllocationAPI — links to an OpenCost-compatible cost allocation endpoint that returns Kubernetes workload cost data broken down by namespace, deployment, or label.
FinOps Practice Documents
Beyond billing data formats, the FinOps Framework defines a set of capabilities that API providers can support and document. Five new types cover the most common FinOps practice artifacts:
- UnitEconomics — links to a document describing the per-unit cost model for an API: cost per API call, per gigabyte processed, per token consumed, per transaction. This is a core FinOps capability for enterprise procurement and cost-aware application design.
- ChargebackPolicy — links to documentation describing how costs are allocated and recovered across teams, cost centers, or business units — covering both chargeback (actual cost transfer) and showback (visibility without transfer).
- TaggingPolicy — links to the cost allocation tag taxonomy for an API or platform, including required tag keys (CostCenter, Environment, Product, Owner) and compliance requirements. Essential for consumers who need to integrate the API into their own FinOps cost allocation workflows.
- InvoiceReconciliation — links to documentation explaining how billing export data maps to issued invoices. FOCUS 1.2 introduced dedicated Invoice ID columns specifically to enable this reconciliation, which is a compliance and audit requirement for enterprise API consumers.
- FinOpsFramework — links to a document describing the provider's alignment to the FinOps Framework — which capabilities they support, at what maturity level, and how they enable customer FinOps practices. The 2025 Framework revision expanded scope to cover cloud, SaaS, data center, and AI.
Sustainability Standards
Carbon intensity and emissions reporting is becoming a supplier due diligence requirement. Three new types cover the most widely used sustainability standards applicable to API services:
- SoftwareCarbonIntensity — links to a published SCI score or methodology document. SCI is an ISO-ratified standard from the Green Software Foundation using the formula
SCI = ((E × I) + M) per R— energy consumed, marginal carbon intensity of electricity, embodied carbon, per functional unit (such as per API call or per user). It is the only ISO-ratified standard specifically designed for measuring the carbon intensity of software. - SCIReport — links to a full calculated carbon intensity report for a specific version or deployment of the API, including methodology, data sources, inputs, functional unit, and resulting score. Distinct from a standing SCI declaration — this is a time-stamped measurement.
- GHGProtocolReport — links to a greenhouse gas emissions report structured according to the GHG Protocol, which defines Scope 1, 2, and 3 emissions categories. Cloud provider carbon dashboards from AWS, Azure, and GCP all align their reporting to GHG Protocol. This type makes provider-level emissions data discoverable by enterprise customers with Scope 3 supply chain reporting requirements.
Naftiko Capability Orchestration
Naftiko is a spec-driven API integration platform for the AI era. Rather than exposing APIs directly, Naftiko wraps them in governed capability specs — single declarative YAML files that define what APIs are consumed upstream, what surfaces are exposed (REST, MCP, Agent Skills simultaneously), and what governance, identity, and telemetry rules apply. Each capability spec is validated by JSON Schema and committed to Git; it is the deployable unit, the documentation, and the governance contract in one artifact.
Two new types cover the Naftiko artifact surface:
- NaftikoCapability — links to a Naftiko capability YAML specification for an API. This is the primary Naftiko artifact: a machine-readable definition that describes the capability's upstream API dependencies, exposed protocol surfaces, and governance constraints. AI agents, orchestration tools, and developer portals can use this link to discover and invoke a governed capability.
- NaftikoFleet — links to a Naftiko fleet catalog that registers and manages a collection of capability specs as a runtime-deployed fleet. The fleet provides the execution environment: routing, identity propagation, observability, and multi-protocol exposure for all capabilities in the collection.
Why These Types Now
The addition of FinOps and sustainability types reflects two converging trends in enterprise API consumption. FinOps has matured from a cloud cost management practice into a formal discipline with open standards — FOCUS is now vendor-certified and machine-readable, and enterprise buyers increasingly expect billing data in a normalized, tooling-compatible format. At the same time, Scope 3 emissions reporting requirements under emerging regulations in the EU, UK, and US are pushing organizations to gather carbon data from their software suppliers.
Making these artifacts discoverable via APIs.json means they can be indexed, audited, and surfaced by tooling the same way OpenAPI specs and documentation are today. A FinOps tool can discover whether a provider publishes a FOCUS export. A procurement platform can surface whether an API has a published SCI score. That's the same value proposition APIs.json has always offered — but applied to a new layer of the API operational surface.
The 0.21 schema draft is available in the apis-json/api-json repository. All thirteen new types are documented at apisjson.org/properties/ and at apicommons.org/common/. If you have feedback or want to propose additional types, open an issue on GitHub.