Require that every successful 2xx response in our OpenAPI definitions includes at least one realistic example, so a consumer can see exactly what a good answer looks like without making a live call...
Require that every 2xx response declares the media types it returns, spelling out application/json or whatever content it actually serves rather than leaving the content negotiation a mystery. I ha...
Require that every 2xx response defines a schema for its body, describing the exact shape, properties, and types a consumer will receive on success rather than handing back an undocumented blob. I ...
Require that our 4xx client-error responses carry real examples, so a developer can see exactly what a validation failure, an unauthorized call, or a missing resource actually returns. I have spent...
Require that every 4xx client-error response declares its media type, so consumers know whether an error comes back as application/json, application/problem+json, or something else entirely. I have...
Require that our 4xx client-error responses define a schema, ideally a consistent error object with a code, a message, and enough detail for a consumer to understand what went wrong and how to fix ...
Require that every 5xx server-error response declares its media type, so that even when our own infrastructure fails, consumers still receive a predictable, parseable body instead of whatever a pro...
Require that our 5xx server-error responses define a schema, reusing the same standardized error object we use elsewhere so a consumer can handle our failures the same way they handle everything el...
Require that every API is registered in a central, searchable catalog with enough metadata that a developer can find it, understand it, and decide to use it without asking anyone. I care deeply abo...
Require that an API invests in educating and enabling its consumers through tutorials, guides, and clear explanations of not just how it works but why. Most friction around APIs comes from gaps in ...
Require that an API documents a clear path for consumers to migrate onto, between, or off of it without being stranded. Lock-in by design erodes trust, so an honest operation makes leaving possible...
Require that every API begins with a design-first contract, an OpenAPI definition authored and agreed upon before a single line of implementation code is written. I have watched too many teams code...
Spectral rules that apply to the API level, linting OpenAPI.
Publishing a license for the interface, client code, server code, and data to ensure consumers understand the legal implications of using the API, code, and data into their own applications and int...
A human and machine-readable schema of the common and agreed upon API lifecycle.
Require that every API can be mocked directly from its contract so consumers and downstream teams can build against it before the implementation is finished. I lean on mocking because it is what ma...
Require that an API is actively communicated through ongoing content and outreach, including blog posts, changelogs, and updates that tell the story of what it does and why it matters. An API launc...
Require that every API is designed to resist abuse and misuse, so I want throttling, quotas, anomaly detection, bot and scraping defenses, and sensible request limits treated as part of the contrac...
I require that every API provider ships an agents.md file that tells an automated consumer exactly how to behave when working with the API, including the conventions, the guardrails, and the workfl...
I require that every API publishes an llms.txt file at a predictable, well-known location so that large language models and the agents built on them can find a concise, curated map of what the API ...
I require that APIs support authentication credentials scoped specifically to agents, so that an autonomous consumer acts under its own narrowly-bound identity with least-privilege scopes rather th...
Require that APIs which chain multiple operations to accomplish real work provide Arazzo workflow definitions describing those sequences. I want the multi-step paths a consumer must follow, the ord...
Require that any API delivering events to consumers describes its webhooks as first-class citizens in the contract, using the OpenAPI webhooks object to define the payloads, headers, and callbacks ...
I require that any event-driven or messaging interface is described with an AsyncAPI document, the same way we insist on OpenAPI for request-response APIs, so that channels, messages, and payloads ...
The details for how to authenticate with an API should always be part of the business and technical contracts for an API. Information on how to authenticate with an API should be readily available ...
Require details regarding how authentication is handled as part of API security.
Require that every API defines and enforces authorization explicitly, so I want each operation to declare what scopes, roles, or permissions it demands and to check them on every request, not just ...
Providing a valid URL to the base for an API that is designed for machines to use when making call to an API by an consumer.
Require that APIs handling high volumes of records offer explicit batch operations rather than forcing consumers to hammer single-resource endpoints in a loop. Every API must define clear semantics...
Require that every API adheres to the shared design best practices we have codified across the platform, so that consistency is a default and not something each team reinvents. Every API must refle...
A blog RSS or Atom feed provides a simple way to syndicate information and updates about APIs with producers and consumers, allowing it to be pushed out to where they are located and regularly cons...
Require that breaking changes to a production API are identified, avoided where possible, and never shipped silently onto an existing version. I hold this line hard because a breaking change you di...
The APIs.json business contract must have a link to the validator for each, providing the ability to run linting rules for each type of contract and see the details of rules as they are applied.
Provide access to business API guidance as part of API contract support.
Require that every browser-facing API sets a deliberate, least-privilege CORS policy, so I want explicit allowed origins, methods, and headers rather than a lazy wildcard slapped on to make an erro...
Require a CSharp client SDK available with each API.
Require that every read-heavy API sets explicit HTTP caching headers, so I want Cache-Control, ETag, and Last-Modified in play with sensible max-age and validation behavior spelled out in the contr...
Every API should define a caching strategy and express it through explicit Cache-Control headers on responses that can safely be reused. I require that providers decide, per operation, what is cach...
Requiring that OpenAPI components headers meet the policy standards.
Requiring that OpenAPI components headers meet the policy standards.
Provide the provenance of an API contract using regular certifications
Having a change log of anything added, updated, or removed for an API, but also for the other operational and supporting resources for each API, ensuring there is a easy to read manifest of what ha...
Require that every change to a production API moves through a defined change management process that assesses impact, tracks dependencies, and communicates what is changing before it lands. I want ...
Every API must maintain a public status page that reports current health, active incidents, and scheduled maintenance in real time. I require that consumers be able to check the state of an API the...
Require that an API provides real channels for its community to engage, whether a forum, chat, mailing list, or regular office hours. Consumers need a place to ask questions, share solutions, and c...
Require that changes to an API preserve backward compatibility by default, and that any deviation is a deliberate, governed decision rather than an accident of a merge. Every API must be designed s...
Require that every API in production maps its endpoints, data, and controls to the specific regulatory and compliance obligations it falls under, whether that is GDPR, HIPAA, PCI DSS, SOC 2, or an ...
Every API that touches personal data must provide a data processing agreement and a clear record of the consent under which that data is handled. I require that the DPA be available to consumers be...
Require that an API honors the rights of its consumers and the people its data represents, including access, correction, portability, and deletion. As APIs become the infrastructure of public and e...
Requiring that there is a contact included in the OpenAPI info.
Require that every API is tested against its own contract in the CI/CD pipeline so the running service can never quietly drift from the OpenAPI it publishes. I insist on contract testing because a ...
Providing the data in which an API contract was created, establishing the inception of a specific contract involving one or more APIs, which defines the age of the contract.
Require that the DNS behind every API be deliberately managed, with ownership, records, and TTLs tracked as part of the API's operational contract. I expect hostnames to be stable, certificates to ...
Require that every API classifies the data it moves and applies protections that match that classification, so I want fields and payloads labeled as public, internal, confidential, or regulated, wi...
Require that an API respects the ownership of the data it handles, treating consumer and end-user data as belonging to them rather than to whoever stores it. Ownership shapes what a provider may do...
Require that consumers can export their data from an API in a portable, standard format without friction or penalty. The data flowing through an API belongs to the people and organizations it descr...
I require that every schema property carrying personally identifiable information is explicitly classified as such in the API definition, so that PII is visible to governance, tooling, and downstre...
I require that every API declares where the data it handles is stored and processed, and that those residency commitments are actually enforced rather than merely stated in a policy document. Consu...
Require that every API declare a written retention policy stating how long each category of data is kept, why it is kept, and when it is destroyed. I expect this policy to be discoverable alongside...
Require that every property in an API contract declares an explicit, well-chosen data type with the right format, precision, and constraints instead of leaning on loose strings and hopeful parsing....
Require usage of date-base versioning for managing change.
Require that every API declares the upstream services, libraries, and other APIs it depends on, and keeps that list current as part of its governance record. I care about this because APIs never st...
Require that every API maintain a current software bill of materials enumerating the libraries, services, and versions it depends on. I want a machine-readable SBOM and dependency manifest kept in ...
Every API must define its deployment environments explicitly, naming where it runs across development, staging, and production and how consumers reach each one. I require that base URLs, credential...
Require that every API be deployed through an automated, repeatable pipeline rather than by hand. I want the path from a merged change to a running endpoint to be codified, versioned, and reproduci...
Require that any API or operation being retired is formally deprecated first, marked in the contract, and announced with a clear sunset date and migration guidance. I treat deprecation as a promise...
Every deprecated API operation must announce itself in-band using Deprecation and Sunset headers that tell consumers a change is coming and when it lands. I require that deprecation be signaled thr...
Requiring that all operational descriptions meets the policy standards.
Requiring the info description property meets the policy standards.
Providing a robust description of each API, providing the right amount of information for consumers to understand what is possible and what the business use case is.
Providing a robust description of the API contract, as well as each API it contains, providing my context for stakeholders of the contract.
The description for the proposed API change in the road map.
Require that any API meant for real adoption is backed by a developer relations function responsible for supporting, advocating for, and growing its community of consumers. Endpoints and documentat...
The human-readable HTML, Markdown, or PDF representation of the technical surface area of each API, providing path, methods, summaries, description, examples, and the other resources consumers will...
Providing examples of request and responses, with as many variations as possible, helping demonstrate wide usage of an API.
Providing simple, clean, and intuitive paths as part of the documentation being published for consumers to use.
Including details and examples regarding the request bodies being submitted for POST, PUT, and other possible methods.
Making sure there is a complete example for each API response in documentation, including happy and unhappy responses.
Documenting all of the schema which are used as part of request bodies and responses, providing JSON SChema representations of each.
Offering other elements or features of an API that are included or not included within a plan to help API consumers understand scope of what is available.
The environments for development, staging, or production environments should be available to manually or automatically working with an API in any environment, providing a machine-readable way for n...
Require that every API returns standardized, informative errors, so I want a consistent error envelope, a correct HTTP status code, a machine-readable code, and a human-readable message on every fa...
I require that every event an API emits is enumerated in a published catalog of event types, each with a stable name, a described payload, and a clear meaning, so consumers know exactly what can ha...
Providing feedback on the business and technical details of each API contract, helping facilitate feedback from consumers and other stakeholders, but also from the learnings across other private an...
Allow for teams to receive feedback on API contracts via Git issue.
Require that collection endpoints offer consistent, documented filtering and sorting, so I want a shared convention for query parameters, allowed fields, operators, and sort order applied the same ...
I require that the full cost of running an API is made visible through FinOps practices, so the people making decisions about an API can see what it actually costs to operate, not just what it earn...
The step by step walk-through for new API consumers, ensuring they have exactly what is needed to discover and onboard, but also help make sure the getting started steps are as simple, plain langua...
Provide a link and description to your API documentation, providing the entry point for API consumers to begin learning about what your API does.
Provide a link and description of where API consumers can learn more about authentication and how it will work when they use an API.
Employing actions as a pipeline to make sure that the deliver of each API is a repeatable process.
GitHub organization provide the ability to have a dedicated README, providing a single landing page for the API workspace of a domain, line of business, or domain, where all API contracts can be fo...
GitHub organizations provide teams with the ability to create repositories for managing API contracts, separating and organizing contracts by meaningful bounded contexts within a specific domain.
GitHub organizations allow for the management of people and teams to help define who has access to repositories, contracts, and other assets managed via this dedicated domain workspace.
A GitHub organization provides a dedicated workspaces for teams to produce APIs, organize all the API contracts in motion, and leverage source countrol, CI/CD, teams, and other resources provided b...
A GitHub repository for an API, providing the single source of truth for the API contract, OpenAPI, and other artifacts, as well as the road map, change log, support, feedback, and other elements o...
Require a Go client SDK available with each API.
Governance standardizes APIs across teams using a common platform and lifecycle, applying governance policies and rules, and keeping everyone moving in the same direction using common guidance.
Human and machine-readable policies that define an aspect of API operations, which are always kept in alignment with business objectives.
A formal vocabulary of words and phrases that can and cannot be used across operations.
I require that any GraphQL API ships a published, versioned schema that we govern like any other contract, with consistent naming, deliberate types, and a clear boundary on what the graph exposes. ...
Ensuring there is guidance for teams throughout their API journey, providing simple text and video guidance for all of the topics business and engineering teams will encounter as part of their regu...
Require that every operation in an OpenAPI definition uses the correct HTTP method for the action it performs, GET to read, POST to create, PUT and PATCH to update, DELETE to remove, and that we do...
Require that every operation documents the HTTP status codes it can actually return, using the standard families the way the web intends, 2xx for success, 3xx for redirection, 4xx for consumer mist...
Require that every API exposes a standard health check endpoint, so I want a predictable path that reports liveness and readiness along with the status of critical dependencies. I insist on this be...
How will consumers be putting API resources and capabilities, getting into the details of programming languages and frameworks.
Providing a valid URL to a landing page for the API that is designed for humans to use when learning more about an API.
Require that APIs return links alongside their data where it helps consumers navigate related resources, discover available actions, and follow state transitions without hardcoding URLs. APIs shoul...
Require that state-changing operations be safe to retry, either because the method is inherently idempotent or because the API supports an idempotency key that lets a consumer replay a request with...
Including images as part of the metadata for your APIs helps make APIs more visible as part of portals, documentation, and other resources.
Including images as part of the metadata for your APIs helps make APIs more visible as part of portals, documentation, and other resources.
Require that every API validates all incoming data against its schema before acting on it, so I want types, formats, lengths, ranges, and required fields checked at the edge and anything that does ...
Require that every API ships interactive documentation generated from its contract, where a developer can read the operations, see the schemas, and make a real call right from the page. I have beli...
Provide the provenance of an API contract using Git issues.
Require JWT usage meets standards set by authentication policies.
Require a Java client SDK available with each API.
Require a JavaScript client SDK available with each API.
Require the API key usage meets standards set by authentication policies.
Requiring the info license property meets the policy standards.
Require that every API contract is automatically linted against our design and governance rules on each commit, so standards are enforced by machines rather than by memory and goodwill. I love lint...
Require that APIs serving a global audience localize the things developers and end users actually experience, from documentation and portal content to error messages, currencies, and date and time ...
Require that every API produces structured, correlated logs for each request, so I want a consistent log schema, a correlation or trace identifier carried through, and clear rules about what gets c...
Require that every API emit standardized, structured logs with consistent fields for request identity, timing, status, and correlation. I expect logs to follow a shared schema across services so th...
Providing a way to login and gain access to an API, offering a simple human-readable URL to the login page, or ideally some sort of automated login process that allows access with as few clicks and...
Require that operations which cannot complete within a normal request window be modeled explicitly as asynchronous, long-running jobs rather than being forced into a single blocking call that ties ...
I require that an API of consequence exposes a Model Context Protocol server so that agents can discover its capabilities and invoke them through a standard, well-understood interface rather than a...
Require that every API names its maintainers, the real people or team accountable for its design, operation, and support, and records them where the contract lives. I care about this from the very ...
Require that every API is scored against a shared maturity model that measures design, documentation, testing, security, and operational readiness, and that the score is visible to the team that ow...
Require that every request and response declares an accurate, standard media type, and that content negotiation is handled deliberately rather than assumed to always be JSON. Every API must be expl...
Unique identifier, name, description, tags, and other metadata for the API that defines the purpose of each individual API, and how it benefits API producer and consumers, establishing the base of ...
Unique identifier, name, description, tags, and other metadata for the contract that defines the purpose of the API Contract, and how it benefits API producer and consumers, establishing the base o...
Providing details regarding the metrics available for each plan, outlining how the usage of digital resources and capabilities are being measured.
Require that whenever an API version is deprecated or a breaking change is introduced, a clear migration guide is published that shows consumers exactly how to move from the old to the new. I insis...
Providing the data in which an API contract was last modified, tracking the change that occurs with each API contract, understanding the velocity as well as stagnation of APIs.
I require that API usage and its costs can be attributed back to the team, application, or consumer that generated them, so the true cost of operating and consuming an API is visible rather than sm...
I require that every monetized API meters usage accurately and makes the units it counts explicit, so both the provider and the consumer agree on exactly what is being measured and billed. Metering...
I require that every API in production publishes its access plans as machine-readable definitions, so consumers can see the tiers, the limits, and the pricing without emailing a salesperson or gues...
Require that every API is actively monitored for availability, latency, error rates, and traffic, so I want the golden signals collected, dashboarded, and wired to alerts before an API ever reaches...
Providing a clear, descriptive, and concise name for each API, as well as the APIs it contains, properly defining the scope, with an intuitive first impression of an API.
Providing a clear, descriptive, and concise name for each API contract, as well as the APIs it contains, properly defining the scope.
Require that every API follows a single, documented set of naming conventions for resources, fields, parameters, and enums, so a developer who learns one of our APIs already understands the next. E...
Require that OAuth usage meets standards set by authentication policies.
Require that OWASP API security top ten has been applied as part of API security.
Every API must be instrumented for observability, exposing metrics, traces, and health signals that let operators understand its behavior in real time. I require that latency, error rates, and thro...
Require that an API operation prefers open source tooling and applies open licensing to its definitions, SDKs, and supporting tools wherever practical. Open source lets consumers understand, extend...
Require that APIs are defined and delivered using open standards such as OpenAPI, AsyncAPI, and JSON Schema rather than proprietary formats. Open specifications lower the cost of adoption, enable i...
A machine-readable OpenAPI using the most recent version of the API specification, describing the surface area of each API, which is then used to render the human-readable documentation, and other ...
Using the OpenAPI specification to describe HTTP APIs.
The OpenAPI Components object enables the centralization of common technical details within an API, promoting modularity and reusability. Using the components object as a standard practice helps re...
Require that consistent, cross-cutting changes to OpenAPI definitions be applied through OpenAPI Overlays rather than by hand-editing each specification. I want shared conventions, added examples, ...
Requiring that OpenAPI security meet the policy standards.
Requiring that all OpenAPI tags meet the policy standards.
Requiring there is the latest version of OpenAPI available.
Require that every operation in our OpenAPI definitions carries a unique, human-readable operationId that follows a consistent naming convention across the whole surface, something like getUser or ...
Requiring that all operational security meets the policy standards.
Requiring that all operational summaries meets the policy standards.
Requiring that all operational tags meets the policy standards.
Spectral rules that apply to the operational level, linting APIs.json.
I require that every operation in an OpenAPI carries a description rich enough that an agent can decide, from the definition alone, what the operation does, when to call it, and what it will get ba...
Require a PHP client SDK available with each API.
Require that every endpoint returning a collection paginates its results using a single, consistent strategy, so I want a documented approach, whether cursor or offset, with clear page-size limits ...
Requiring that all operational parameters descriptions meets the policy standards.
Requiring that all operational parameters enums meets the policy standards.
Requiring that all operational parameters in property meets the policy standards.
Requiring that all operational parameters names meets the policy standards.
Requiring that all operational parameters schema meets the policy standards.
Requiring that all operational parameters type property meets the policy standards.
Requiring that all operational parameters meets the policy standards.
Requiring API paths meets the policy standards that are set.
Require that our OpenAPI paths follow one consistent rule about trailing slashes, and I strongly prefer no trailing slash so that /orders and /orders/ never become two subtly different things. I ha...
Provide access to people API guidance as part of API contract support.
Publishing details regarding the performance of APIs, complimenting status and uptime information, but drilling into more detail regarding speed, latency, and other performance related metrics that...
Require that every API define performance budgets, setting explicit targets for latency, throughput, and error rates that it commits to holding. I expect these budgets to be measured continuously a...
Plans are all about being explicit and transparent with all of the access for an API, breaking down the tiers, rate limits, features, and pricing that is available for API consumers, standardizing ...
Providing the machine-readable policies that link machine-readable rules with the business reasons why we are governing an API and the operations around it, helping organize rules based upon the bu...
Require that any deviation from a governance policy is requested, justified, time-boxed, and approved through a documented exception process rather than quietly ignored. I have learned that rigid r...
Provide access to API policy guidance as part of API contract support.
A machine-readable Postman Collection describing the surface area of the API contract or providing more modular and executable representations of portions of the API contract. - Postman - Executable
A Postman Workspace provides a dedicated space to manage API contracts within a domain, complimenting other types of workspaces, allowing for private, partner, and public workspaces to exist for ma...
Publishing a privacy policy covering the producer and consumers of an API, as well as end-users of applications, adding to the legal resources that are available to 3rd party developers when puttin...
Requiring that errors use the Problem Details for HTTP APIs standard.
Require that every API considered for adoption be run through a documented procurement evaluation checklist before a team commits to it. I want the same questions asked each time, covering security...
Helping curate the provenance of each API contract as it evolves over time, documenting change, and cataloging the reviews, validation, certification, and conversation that occurs as each API moves...
Requiring that all OpenAPI external documentation meet the policy standards.
Provide the provenance of an API contract using Git pull requests.
Using pull requests to submit changes to business or technical artifacts.
Empowering teams to ask questions via issue or discussion via Git repository, or directly via email about the API lifecycle, governance, as well as the business or technical elements of producing a...
Allow for teams to ask questions and get answers via Git Issues.
Require that every API enforces rate limits and communicates them clearly, so I want defined quotas per consumer, standard headers that report remaining budget, and a proper 429 with a Retry-After ...
Providing details of rate limits being applied as part of each plan, and what is available to consumers as part of their application usage.
Providing regional details available for access API resources and capabilities in different geographical regions as part of API plan usage.
Requiring that all operational request bodies meets the policy standards.
Requiring that all operational request body examples meets the policy standards.
Requiring that all operational request body media types meets the policy standards.
Requiring that all operational request body schema meets the policy standards.
Requiring that all 2xx responses meets the policy standards.
Requiring that all 4xx responses meets the policy standards.
Requiring that all 5xx responses meets the policy standards.
Requiring details regarding the regular response time for each available API.
Require that retiring an API is a deliberate, documented step that only happens after a deprecation period, with the shutdown date, the reason, and the alternative all made clear to consumers. I wa...
Require that every API carry a reuse score that measures how widely and effectively it is being reused across teams and how much it duplicates existing capabilities. I want reuse assessed with a co...
Require that every API design and significant change passes through a documented review and approval step before it ships, with clear owners and clear criteria. I am a big believer in design-first ...
Provide the provenance of an API contract using API governance reviews.
Require that APIs are designed for robustness on both sides of the wire, being conservative in what they send and tolerant in what they accept, so that small variations do not cascade into outages....
Providing the machine-readable rules used to govern an API that can be used as part of pipelines or other automation to lint an API, making sure the baseline for each API and the operations around ...
Offering software development kits, or SDKs for an API, handling authentication, and working across all available API operations in a variety of relevant programming languages to the targeted consu...
Provide a link and description of where API consumers can get access to SDKs, libraries, and the code that will jumpstart their integration with an API.
Require that every API published for consumers carries a clear service level agreement stating its uptime target, expected performance, support commitments, and what happens when we fall short. I p...
I require that every production API defines a service level agreement and publishes it where consumers can find it, stating the availability, performance, and support commitments we are willing to ...
Require that every API offers a sandbox environment with test credentials and safe, representative data so a developer can experiment fully before touching production. I champion sandboxes because ...
Require that our schemas express real constraints on their properties, the minLength and maxLength, minimum and maximum, patterns, and formats that describe what valid data actually is rather than ...
Requiring that all schema descriptions meets the policy standards.
Requiring that all schema names meets the policy standards.
Requiring that all schema properties meets the policy standards.
Requiring that all schema property descriptions meets the policy standards.
Require that any property with a fixed set of allowed values declares those values as an enum in the schema, so status, type, and category fields cannot drift into a free-for-all of typos and inven...
Requiring that all schema property names meets the policy standards.
Require that our schemas explicitly list which properties are required, so consumers know which fields they can always count on and which ones may be absent. I have written code that trusted a fiel...
Requiring that all schema property shapes meets the policy standards.
Requiring that all schema property types meets the policy standards.
Require that the schemas an API relies on are published to a shared schema registry and validated against it in CI/CD, so the shapes of our data are versioned, discoverable, and compatible. I want ...
Require that every request and response body in our OpenAPI definitions references a defined schema rather than accepting or returning free-form, untyped content. I have run into operations that de...
Requiring that all schema type meets the policy standards.
Require Oauth scopes meets standards set by authentication policies.
Providing an overview of security practices for an API, including details covered as part of authentication and access management, but also security testing and certifications that matter to API co...
Require usage of major, minor, and patch Semantic Versioning for managing change.
Require that every OpenAPI definition declares its servers, the concrete base URLs where the API actually lives, ideally with an entry for each environment so production and sandbox are both discov...
Internet, industry, market, and government standards help make APIs more consistent, but also save time and money for both producer and consumer, while keeping APIs better aligned with existing ind...
Making an API status page, monitoring reports, or other real-time updates regarding the uptime and availability of an API, providing current, but also the historical status of API, helping maintain...
Require a link to as well as results from a status dashboard for an API.
Require a link to as well as results from a status history for an API.
Outline what support is available for API consumers, including email, tickets, forums, and paid support services, making it easy for API consumers to understand how they can get the help they need ...
Require that every API publish clear support channels so consumers know exactly how to get help and what to expect when they ask. I want the path to a human, an issue tracker, or a community forum ...
Require that an API is supported using email.
Require that an API is supported using Git issues.
Tags provide a bounded context for your APIs, providing keywords that help organize APIs by domains, and make them more discoverable.
Tags provide a bounded context for your APIs, providing keywords that help organize APIs by domains, and make them more discoverable.
The OpenAPI technical contract must have a link to the validator for each, providing the ability to run linting rules for each type of contract and see the details of rules as they are applied.
Provide access to technical API guidance as part of API contract support.
Making sure that terms of service are front and center for API consumers, ensuring that the legal side of using API resources and capabilities in applications and integrations by 3rd party consumer...
Requiring the info terms of service property meets the policy standards.
Require that security testing has occurred and publishing results for API security.
Break down usage for for consumers based upon second, minutes, days, weeks, months, or other relevant time-frame for them to understand their usage.
The title for the proposed API change in the road map.
Requiring the info title property meets the policy standards.
I require that APIs publish explicit tool definitions that describe each callable capability as a discrete tool an agent can select, with clear names, descriptions, and typed inputs and outputs. Th...
Require that every API is served exclusively over encrypted transport, so I want TLS enforced everywhere, plain HTTP either redirected or refused, weak protocols and ciphers disabled, and HSTS in p...
Require that every API uses a consistent, predictable URL structure, with clear resource hierarchies, sensible pluralization, and paths that read like the nouns of the domain rather than a grab bag...
Providing the valid URL for the APIs.json contract, identifying the source of the contract which may or may not be where it is found, helping make contract authoritative.
Providing unique identifiers for API apis, as well as the APIs that are indexed as part of an API, providing a key reference for discovery and automating around a contract.
Providing unique identifiers for API contracts, as well as the APIs that are indexed as part of a contract, providing a key reference.
Requiring that all operational unique identifiers meets the policy standards.
Using JSON Path to identify properties of a schema.
Require that every API defines and enforces validation rules in its contract, using schemas, constraints, required fields, and formats so that bad input is rejected with a clear, consistent error i...
The version of the proposed API change in the road map.
Requiring the info version property meets the policy standards.
Providing semantic or date-based versioning for an API, offering an overview of what is adopted for an API and why, letting consumers know that their is change management in place and how they can ...
I require that every webhook an API sends is described by a real contract that specifies its trigger, its payload, its headers, and its delivery and retry behavior, so integrators can build against...
What will consumers be building with the resources and capabilities being made available via APIs.
Who is using an API, focusing on the people who will be putting an API to work in their applications.
What are the reasons an API consumer will be putting APIs to work in their applications and integrations as part of their business.
