API Contract for the APIs.io Search API

This is the API contract for the APIs.io API search API, which provides a manifest of the business and technical details for the API. This README is autogenerated from the APIs.json (Business) and OpenAPI (Technical) contracts for the APIs.io Search API.

This contract is meant to address the needs of both API producer and consumer, helping ensure everyone's needs are being met as this API evolves and changes.

The business and technical needs of this API, and other APIs.io APIs, are aligned using an API Evangelist strategy, policies, and the rules that are applied to the APIs.json, OpenAPI, and other machine-readable artifacts included in this contract.

APIs are Defined as API Contracts

All APIs are defined as API contracts so that we can align both the business and technology of delivering consistent high quality APIs, employing source control to manage the technical, but also the business side of things, while actively checking in on the alignment between the two over time.

	API Contract Metadata			Policy	Guidance
	→ Unique Identifiers	apis-io		Policy	Guidance
	✅ There is an aid.			Rule	Guidance
	→ Name	API Contract for the APIs.io Search API		Policy	Guidance
	✅ There is a name.			Rule	Guidance
	→ Descriptions	This is the API contract for the APIs.io API search API, which provides a manifest of the business and technical details for the API. This README is autogenerated from the APIs.json (Business) and OpenAPI (Technical) contracts for the APIs.io Search API. This contract is meant to address the needs of both API producer and consumer, helping ensure everyone's needs are being met as this API evolves and changes. The business and technical needs of this API, and other APIs.io APIs, are aligned using an API Evangelist strategy, policies, and the rules that are applied to the APIs.json, OpenAPI, and other machine-readable artifacts included in this contract.		Policy	Guidance
	✅ There is a description.			Rule	Guidance
	→ Images	https://kinlane-productions2.s3.amazonaws.com/apis-io/apis-io-api-logo.jpg		Policy	Guidance
	✅ There is an image.			Rule	Guidance
	→ Tags	APIs,Search Engine,Directory		Policy	Guidance
	✅ There is a Tags Object			Rule	Guidance
	✅ Tags Upper Case			Rule	Guidance

APIs Possess Informative Metadata

All APIs possess metadata that is relevant to what APIs do, but also how they can be used in business by API consumers, and metadata helps ensure that the front door for API operations within this domain is always one click away, and present in all artifacts we use to support API operations.

	API Metadata			Policy	Guidance
	→ Unique Identifiers	apis-io:search-api		Policy	Guidance
	✅ API has an aid property.			Rule	Guidance
	→ Name	APIs.io Search API		Policy	Guidance
	✅ Has a Name			Rule	Guidance
	→ Description	This is the API to access APIs.io API search engine, from the product management perspective.		Policy	Guidance
	✅ Has a Description			Rule	Guidance
	→ Image	https://kinlane-productions2.s3.amazonaws.com/apis-io/apis-io-api-logo.jpg		Policy	Guidance
	✅ Has an Image			Rule	Guidance
	→ Tag	APIs,Search Engine,Directory		Policy	Guidance
	✅ API Have a Tags Object			Rule	Guidance
	✅ API Tags are Upper Case			Rule	Guidance

APIs Have One Click Access

All APIs possess a URL for humans to follow when engaging as well as the base path URL for machines to use when calling each API, ensuring that the front door for API operations within this domain is always one click away, and present in all artifacts supporting humans and the applications.

	URL	https://github.com/api-search/search-api/blob/main/apis.yml		Policy	Guidance
	✅ There is a URL.			Rule	Guidance
	Human URL	https://developer.apis.io/documentation		Policy	Guidance
	✅ Has a Human URL			Rule	Guidance
	Base URL	https://search-api.apis.io		Policy	Guidance
	✅ APIs Has a Base URL			Rule	Guidance

Operations

All of the individual operations that are defined in the technical contract (OpenAPI), allowing for alignment of the resources being made available and the use cases articulated as part of the business contract.

	/search/apis	Search APIs	Searching across all APIs by keyword or phrase.
	/search/apis	Submit API	Submit a valid APIs.json to be included in APIs.io.

API Paths Must Conform to the Organization

All API paths must conform to the overall organizational domain standards, utilizing plain language and a resourceful approach to delivering digital resources and capabilities via HTTP APIs, providing a common set of paths that can be used and reused across many different applications and consumers.

	Path Names		Policy	Guidance
	❌ No API in Path		Rule	Guidance
	✅ Path Trailing Slash		Rule	Guidance
	✅ Version in Path		Rule	Guidance

API Operations Must Be Useful and Consistent

All individual API operations must be useful and follow consistent Internet, industry, and enterprise standards, providing a simple and relevant HTTP API operation that does one thing and does it well, making the value intuitive to API consumers who will be using each API operation.

	Operation Ids		Policy	Guidance
	✅ Operation Has Identifier		Rule	Guidance
	❌ Operation Identifier MUST Be camelCase		Rule	Guidance
	Operation Summary		Policy	Guidance
	✅ Operation Has a Summary		Rule	Guidance
	✅ Operation Has a Period.		Rule	Guidance
	Operation Description		Policy	Guidance
	✅ Operation Has Description		Rule	Guidance
	Request Bodies		Policy	Guidance
	✅ GET Request Body		Rule	Guidance
	✅ Request Body Content POST		Rule	Guidance
	Request Bodies Media Types		Policy	Guidance
	✅ Request Body Application JSON		Rule	Guidance
	Request Bodies Schema		Policy	Guidance
	✅ Request Body Schema		Rule	Guidance
	✅ Request Bodies Use Schema Reference		Rule	Guidance
	✅ POST Requests Has a Body		Rule	Guidance
	Parameters		Policy	Guidance
	✅ Parameters use components $ref.		Rule	Guidance
	Parameter In		Policy	Guidance
	✅ Parameters In Property Is Set		Rule	Guidance
	Parameter Names		Policy	Guidance
	✅ Parameters Have a Name		Rule	Guidance
	Parameter Descriptions		Policy	Guidance
	✅ Parameters Have a Description		Rule	Guidance
	Parameter Type		Policy	Guidance
	✅ Schema Array Properties Has Items		Rule	Guidance
	❌ Schema Array Properties MUST Have Max Items		Rule	Guidance
	❌ Schema Array Properties MUST Have Min Items		Rule	Guidance
	❌ Schema String Properties MUST Have Maximum Length		Rule	Guidance
	❌ Schema String Properties MUST Have Minimum Length		Rule	Guidance
	Parameter Schema		Policy	Guidance
	✅ Parameters Have Schema		Rule	Guidance
	✅ Parameters Use Schema Reference		Rule	Guidance
	Parameter Enumerators		Policy	Guidance
	Operation Tags		Policy	Guidance
	✅ Operations Has Tags		Rule	Guidance
	✅ Operation Tag Names Have First Letter in Each Word Capitalized		Rule	Guidance
	Operation Security		Policy	Guidance
	❌ Operations MUST Have a Security Definition		Rule	Guidance

API Responses Must Be Meaningful and Consistent

All API responses should follow Internet, industry, and enterprise standards, providing a meaningful and consistent communication and structure, always providing what was intended for API consumers, while ensuring things are always as simple as possible--always reducing the cognitive load.

	Response 2xx		Policy	Guidance
	✅ GET Responses Has 200 Status Codes		Rule	Guidance
	✅ GET 200 Response has description.		Rule	Guidance
	✅ GET 200 Response Has Content.		Rule	Guidance
	✅ GET 200 Response Has Media Type.		Rule	Guidance
	✅ GET 200 Response Has Schema		Rule	Guidance
	✅ GET 200 Responses Uses Schema Reference		Rule	Guidance
	✅ GET 200 ResponseHas Examples		Rule	Guidance
	✅ GET 200 Responses Uses Examples Reference		Rule	Guidance
	✅ POST 201 Responses Has Schema		Rule	Guidance
	✅ POST 201 Responses Has Schema Reference		Rule	Guidance
	✅ POST Responses Has 201 Status Codes		Rule	Guidance
	✅ POST 201 Responses Has Description		Rule	Guidance
	✅ POST 201 Responses Has Content		Rule	Guidance
	✅ POST 201 Responses Has Media Type		Rule	Guidance
	✅ POST 201 Responses Has Examples		Rule	Guidance
	✅ POST 201 Responses Has Examples Reference		Rule	Guidance
	Response 4xx		Policy	Guidance
	✅ GET Responses Has 400 Status Codes		Rule	Guidance
	✅ GET Responses MUST Have 401 Status Code		Rule	Guidance
	✅ GET Responses MUST Have 403 Status Code		Rule	Guidance
	✅ GET Responses MUST Have 429 Status Code		Rule	Guidance
	✅ GET 400 Responses Uses Schema Reference		Rule	Guidance
	✅ GET 401 Responses Has Schema Reference		Rule	Guidance
	✅ GET 403 Responses Uses Schema Reference		Rule	Guidance
	✅ GET 404 Responses Uses Schema Reference		Rule	Guidance
	✅ GET 429 Responses Uses Schema Reference		Rule	Guidance
	✅ POST Responses MUST Have 400 Status Codes		Rule	Guidance
	✅ POST Responses MUST Have 401 Status Codes		Rule	Guidance
	✅ POST Responses MUST Have 403 Status Codes		Rule	Guidance
	✅ POST Responses MUST Have 404 Status Codes		Rule	Guidance
	✅ POST Responses Has 429 Status Codes		Rule	Guidance
	✅ POST 400 Responses Uses Schema Reference		Rule	Guidance
	✅ POST 401 Responses Uses Schema Reference		Rule	Guidance
	✅ POST 403 Responses Uses Schema Reference		Rule	Guidance
	✅ POST 404 Responses Uses Schema Reference		Rule	Guidance
	✅ POST 429 Responses Uses Schema Reference		Rule	Guidance
	Response 5xx		Policy	Guidance
	✅ GET Responses Has 500 Status Code		Rule	Guidance
	✅ GET 500 Responses Uses Schema Reference		Rule	Guidance
	✅ POST Responses Has 500 Status Codes		Rule	Guidance
	✅ POST 500 Responses Uses Schema Reference		Rule	Guidance

API Data Should Be Well-Defined and Validated

The schema for data that is sent and received via API should always be well-defined, possess a well-known shape, and always be validated, ensuring that digital resources and capabilities are what they should be, and only accessible to those who should have access our API digital resources.

	Schema Type		Policy	Guidance
	❌ Schema MUST Have Type Property		Rule	Guidance
	Schema Names		Policy	Guidance
	❌ Schema Names MUST Be PascalCase.		Rule	Guidance
	Schema Descriptions		Policy	Guidance
	❌ Schema MUST Have a Description.		Rule	Guidance
	Schema Property Names		Policy	Guidance
	✅ Schema Property Names Are camelCase.		Rule	Guidance
	Schema Property Descriptions		Policy	Guidance
	❌ Schema Properties MUST Have Description		Rule	Guidance
	Schema Property Type		Policy	Guidance
	✅ Schema Array Properties Has Items		Rule	Guidance
	Schema Property Shapes		Policy	Guidance
	❌ Schema String Properties MUST Have Maximum Length		Rule	Guidance
	❌ Schema String Properties MUST Have Minimum Length		Rule	Guidance
	✅ Schema Array Properties Has Items		Rule	Guidance
	❌ Schema Array Properties MUST Have Max Items		Rule	Guidance
	❌ Schema Array Properties MUST Have Min Items		Rule	Guidance

API Operations Must Always Be Secure

Individual API operations should always be properly secured during design, develop, and run-time, making sure data, credentials, logs, and all other related resources are properly secured and operating as expected by both the API producer and the consumer--protecting both parties equally.

	OpenAPI Security		Policy	Guidance
	✅ Components Have a Security Schemes		Rule	Guidance

APIs Must Reusable Whenever Possible

The components of any API should be made modular and reusable whenever it makes sense to the business use case, keeping schema, parameters, examples, error responses, and other common parts of an API as reusable and interchangeable as possible within a single API, but also across all APIs.

	OpenAPI Components		Policy	Guidance
	✅ There is an common property.		Rule	Guidance
	✅ Components Have a Parameters Property		Rule	Guidance
	✅ Components Have a Examples Property		Rule	Guidance
	✅ Components Have a Schema Property		Rule	Guidance
	❌ Components MUST Have a Headers Property		Rule	Guidance

APIs are Defined by Technical Contracts

All APIs must have machine-readable artifacts that defines the technical surface area of each API being made available to API consumers, utilizing open-source community specifications like OpenAPI and JSON Schema to define the technical details of each API that is being made available.

	OpenAPI	Visit	Policy	Guidance
	✅ Has An OpenAPI		Rule	Guidance
	Postman Collection	Visit	Policy	Guidance
	✅ Has a Postman Collection		Rule	Guidance

APIs Are Always Well Documented

All APIs must have human-readable documentation that defines the technical surface area of each API being made available to API consumers, providing a simple, intuitive, and ideally interactive HTML representation of APIs, methods, operations, requests, responses, errors, and other elements.

	Documentation	Visit	Policy	Guidance
	✅ Has Documentation		Rule	Guidance

Producing APIs MUST Be Repeatable

All APIs must have a single source of truth for all artifacts, as well as the conversations and always be able to be delivered using a repeatable process, leveraging existing software development infrastructure to ensure for continuous integration and delivery consistently across all APIs.

	GitHub Repository	Visit	Policy	Guidance
	✅ Has a GitHub Repository		Rule	Guidance
	GitHub Actions	Visit	Policy	Guidance
	✅ Has a GitHub Action		Rule	Guidance

APIs Are Made Available Through a Platform Gateway

All APIs must be deployed through a common platform gateway established for the domain, line of business, or team, leveraging development, staging, and production environments, and a common set of policies for configuring access to digital resources and capabilities via APis.

	Gateway	Visit	Policy	Guidance
	✅ Has Staging Gateway for API		Rule	Guidance
	Environments	Visit	Policy	Guidance
	✅ Has a Stage Environment		Rule	Guidance

APIs Are Always Aligned with Business

All API contracts must have use cases that align the business reasons why an API is being delivered to consumers with the actual technical details of each API contract, ensuring that operations all have a valid business use case.

	Use Cases	Visit	Policy	Guidance
	✅ Has Use Cases		Rule	Guidance
	→ Who		Policy	Guidance
	→ APIs.io Website Developer → APIs.io Backend Developer → APIs.io Researcher
	→ What		Policy	Guidance
	→ Open-Source API Search Engine → API Search and Crawler → Profiling APIs
	→ How		Policy	Guidance
	→ Client-Side Javascript Calls → Scheduled API Requests → Postman Collections
	→ Why		Policy	Guidance
	→ Power the Network Websites → Automate Discovery of New APIs → Profiling of New APIs

Change is Actively Managed for Each API

All APIs must have change management baked into the definition, delivery, and iteration, ensuring that producers and consumers are in alignment regarding the communication, quality, and velocity of change that is occurring for each individual API, driving planning as well as API provenance.

	Road Map	Visit	Policy	Guidance
	✅ Has a Road Map		Rule	Guidance
	→ Add Lifecycle to README - Add the lifecycle to the readme, listing stages with policies grouped by stage show what has been done and needs to be done. → Property Search - Add the ability to search by property. → Maintainer Search - Add the ability to search by maintainer. → Add Tag Search - Enable the ability to search by tags. → Add Rating System - Currently the rating system for APIs is not available in the API search API, so we need to formally add it as part of the next iteration.
	Change Log	Visit	Policy	Guidance
	✅ Has Change Log		Rule	Guidance
	→ Add Use Cases - Add the first draft of the use case schema as individual file and link it like OpenAPI using it's own property.YAML - https://github.com/api-search/search-api/blob/main/use-cases.yml → Auto Generate README - Generate the README from the APIs.json, parsing all the URLS, applying operational and API rules that are organized by strategy and policy--providing links to gudiance. → Created GitHub Repository - The 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 of a repository.

APIs Are Always High Quality and Reliable

All APIs should be high quality and reliable, providing adequate levels of monitoring of its availability and performance, with the proper provenance and communication with producer and consumers regarding quality of the APIs, as well as with any future release of API resources.

	Status	Visit	Policy	Guidance
	✅ Has a Status Page		Rule	Guidance
	Performance	Visit	Policy	Guidance
	✅ Has API Performance		Rule	Guidance

APIs Always Have Well-Defined Owners and Stakeholders

Each API should ideally have a dedicated product as well as an engineering owner, with other stakeholders across the API lifecycle defined in an easy to access human readable location, but also defined in a machine-readable API to help automate coordination amongst owners and stakeholders.

	Teams	Visit	Policy	Guidance
	✅ Has a Team Defined		Rule	Guidance
	→ Steve Willmott (CEO) - Steve Willmott is leading the business side of APIs.io, owning all the product and other business aspects of building APIs.io. → Kin Lane (CTO) - Kin Lane is leading the technical side of APIs.io, helping define and roll-out the infrastructure, while profiling APIs.

APIs Are Aligned with Industry Using Standards

All APIs must be using relevant Internet, industry, and government standards available, ensuring to properly research areas of operations to see what existing standards may exist before the creation of any new schema or process, helping align operations with the wider industry API landscape.

	Standards	Visit	Policy	Guidance
	→ HTTP		Policy	Guidance
	→ JSON		Policy	Guidance
	→ YAML		Policy	Guidance
	→ OpenAPI		Policy	Guidance
	→ JSON Schema		Policy	Guidance
	→ Spectral		Policy	Guidance
	→ Problem Details for HTTP APIs		Policy	Guidance
	✅ Components has a responses property.		Rule	Guidance
	✅ Components has a bad request response.		Rule	Guidance
	✅ Components has a conflict response.		Rule	Guidance
	✅ Components has a forbidden response.		Rule	Guidance
	✅ Components has a internal server error response.		Rule	Guidance
	✅ Components has a not found response.		Rule	Guidance
	✅ Components has a too many requests response.		Rule	Guidance
	✅ Components has a unauthorized response.		Rule	Guidance
	→ JSON Path		Policy	Guidance

APIs Operations Possess Dedicated Workspaces

API operations should provide dedicated workspace for domains, lines of business, and teams who are producing APIs, providing a dedicated location where work, collaboration, and automation can occur around APIs establishing the virtual factory floor that exist across enterprise API operations.

	GitHub Organization	Visit	Policy	Guidance
	✅ Has a GitHub Organization		Rule	Guidance
	Postman Workspace	Visit	Policy	Guidance
	✅ Has Public Postman Workspace		Rule	Guidance

Onboarding is Always as Easy as Possible

API operations is made easier by making common elements like documentation, authentication, SDKs easy to find and available as just a couple of simple steps that API consumers can follow when it comes to onboarding with an API, helping producers simplify the onboarding for their consumers.

	Portals	Visit	Policy	Guidance
	✅ Has Developer Portal		Rule	Guidance
	Getting Started	Visit	Policy	Guidance
	✅ Has Getting Started		Rule	Guidance
	Plans	Visit	Policy	Guidance
	✅ Has API Plans		Rule	Guidance
	SDKs	Visit	Policy	Guidance
	✅ Has SDK		Rule	Guidance

API Change is Relative to Operational Change

Individual APIs should be aligned with overall operational change, providing a common operational change log and road-map that is higher level than change for each individual API, but provides a common context across all APIs, teams, and lines of business--keeping everyone in alignment.

	Created Date		Policy	Guidance
	✅ There is a created date.		Rule	Guidance
	Modified Date		Policy	Guidance
	✅ There is a modified date.		Rule	Guidance
	Road Map	Visit	Policy	Guidance
	✅ Has a Road Map		Rule	Guidance
	Change Log	Visit	Policy	Guidance
	✅ Has Change Log		Rule	Guidance
	Versioning	Visit	Policy	Guidance
	✅ Has Versioning for API		Rule	Guidance
	→ Semantic Versioning		Policy	Guidance
	→ Date-Based Versioning		Policy	Guidance

APIs Work Across Multiple Programming Languages

All APIs should have SDK and other client or server code available in multiple programming languages used by targeted API consumers for known business use cases, making it as simple as possible for consumers to put an API to use in their own language and frameworks, via their own infrastructure.

	SDKs	Visit	Policy	Guidance
	✅ Has SDK		Rule	Guidance

APIs Are Legally Covered

All APIs must be reviewed by legal council and posses terms of service, privacy policy, licensing, and other regulatory and compliance requirements, making sure all the legal bases are covered before any API is made available to any external consumers of digital resources.

	Terms of Service	Visit	Policy	Guidance
	✅ Has an API Terms of Service		Rule	Guidance
	Privacy Policy	Visit	Policy	Guidance
	✅ Has an API Privacy Policy		Rule	Guidance
	Licensing	Visit	Policy	Guidance
	✅ Has Interface License		Rule	Guidance

APIs Must Be Actively Governed

All APIs being produced must be governed as part of the overall strategy, using the platform, as well as a common API lifecycle, applying policies and rules, and keeping teams moving in the same direction using guidance, and speaking the same language with a common API vocabulary.

	Governance	Visit	Policy	Guidance
	→ Policies	Visit	Policy	Guidance
	✅ Has API Governance Policies		Rule	Guidance
	→ Operational Rules	Visit	Policy	Guidance
	✅ Has Operational Rules		Rule	Guidance
	→ API Rules	Visit	Policy	Guidance
	✅ Has API Rules		Rule	Guidance
	→ Lifecycle	Visit	Policy	Guidance
	✅ Has an API Lifecycle		Rule	Guidance
	→ Vocabulary	Visit	Policy	Guidance
	✅ Has Vocabulary		Rule	Guidance
	→ APIs - An application programming interface, which is often shortened to just API. → Search - Try to find something by looking or otherwise seeking carefully and thoroughly.

APIs Are Part of Regular Active Communication

All APIs are considered and included as part of regular internal and external communication channels, sharing road maps, change logs, blog posts, videos, and other relevant information that producers and consumers will find useful around their regular technical or business applications.

	Blogs	Visit	Policy	Guidance
	✅ Has a Blog Feed		Rule	Guidance
	Blog Feeds	Visit	Policy	Guidance
	✅ Has a Blog Feed		Rule	Guidance
	Videos	Visit	Policy	Guidance
	✅ Has Videos for API		Rule	Guidance

APIs Must Be Supported and Have Feedback Loops

All APIs must have support mechanisms to ensure API consumers have self-service or direct support channels, as well as regular feedback loops for soliciting feedback or answering specific API questions from consumers, going beyond the problems consumers may have encountered using APIs.

	Support	Visit	Policy	Guidance
	✅ Has Support Page		Rule	Guidance
	→ Support Email	Visit	Policy	Guidance
	✅ Has Support Email		Rule	Guidance
	→ Support Issues	Visit	Policy	Guidance
	✅ Has Support Issues URL		Rule	Guidance
	Feedback	Visit	Policy	Guidance
	→ Feedback Issues	Visit	Policy	Guidance
	✅ Has Feedback Issues URL		Rule	Guidance
	Questions	Visit	Policy	Guidance
	→ Questions Issues	Visit	Policy	Guidance
	✅ Has Questions Issues URL		Rule	Guidance

API Contracts Are Validated

All APIs must have a link to the evidence of the contract validation for business and technical contracts, allowing any stakeholder to review the details of the contract, as well as the rules applied to govern the details of contracts.

	Business Contract Validator	Visit	Policy	Guidance
	✅ Has APIs.json (Business) Validator		Rule	Guidance
	Technical Contract Validator	Visit	Policy	Guidance
	✅ Has OpenAPI (Technical) Validator		Rule	Guidance

API Lifecycle

This is the API lifecycle being applied to this API, organizing the policies above by each stage of API development, rather than by strategy area, helping understand when things need to happen, and automating the governance of APIs by each individual stage.

	Define		Guidance
	→ GitHub Organization	Policy	Guidance
	→ GitHub Repository	Policy	Guidance
	→ Postman Workspace	Policy	Guidance
	→ Teams	Policy	Guidance
	→ Standards	Policy	Guidance
	→ Use Cases	Policy	Guidance
	→ API Contract Metadata	Policy	Guidance
	→ API Metadata	Policy	Guidance
	→ Road Map	Policy	Guidance
	→ Change Log	Policy	Guidance
	→ Questions	Policy	Guidance
	→ Governance	Policy	Guidance
	Design		Guidance
	→ OpenAPI	Policy	Guidance
	→ OpenAPI Components	Policy	Guidance
	→ Path Names	Policy	Guidance
	→ Operation Ids	Policy	Guidance
	→ Operation Summary	Policy	Guidance
	→ Operation Description	Policy	Guidance
	→ Request Bodies	Policy	Guidance
	→ Request Bodies Media Types	Policy	Guidance
	→ Request Bodies Schema	Policy	Guidance
	→ Parameters	Policy	Guidance
	→ Parameter In	Policy	Guidance
	→ Parameter Names	Policy	Guidance
	→ Parameter Descriptions	Policy	Guidance
	→ Parameter Type	Policy	Guidance
	→ Parameter Schema	Policy	Guidance
	→ Parameter Enumerators	Policy	Guidance
	→ Operation Tags	Policy	Guidance
	→ Operation Security	Policy	Guidance
	→ Response 2xx	Policy	Guidance
	→ Response 4xx	Policy	Guidance
	→ Response 5xx	Policy	Guidance
	→ Schema Type	Policy	Guidance
	→ Schema Names	Policy	Guidance
	→ Schema Descriptions	Policy	Guidance
	→ Schema Property Names	Policy	Guidance
	→ Schema Property Descriptions	Policy	Guidance
	→ Schema Property Type	Policy	Guidance
	→ Schema Property Shapes	Policy	Guidance
	→ Postman Collection	Policy	Guidance
	→ Documentation	Policy	Guidance
	Develop		Guidance
	→ OpenAPI Security	Policy	Guidance
	→ GitHub Actions	Policy	Guidance
	→ Base URL	Policy	Guidance
	→ SDKs	Policy	Guidance
	Staging		Guidance
	→ Human URL	Policy	Guidance
	→ Portals	Policy	Guidance
	→ Getting Started	Policy	Guidance
	→ Plans	Policy	Guidance
	→ Status	Policy	Guidance
	→ Performance	Policy	Guidance
	Production		Guidance
	→ Support	Policy	Guidance
	→ Feedback	Policy	Guidance
	→ Blogs	Policy	Guidance
	→ Blog Feeds	Policy	Guidance
	→ Videos	Policy	Guidance
	→ Terms of Service	Policy	Guidance
	→ Privacy Policy	Policy	Guidance
	→ Licensing	Policy	Guidance

APIs.io Engineering Platform

This is an index of all of the infrastructure and services used to operate the engineering side of APIs.io, providing a single manifest of all the 3rd-party suppliers we depend on for digital resources and capabilities.

The goal of this engineering platform definition is to define the platform in a way that can be federated and distributed as part of API operations, helping educate teams where they can access platform resources.

	Amazon S3	Amazon S3 is used for centralized object storage, managing all images, video, and audio across sites via public and private buckets.	Guidance
	AWS Lambda	AWS Lambda is an event-driven, serverless Function as a Service provided by Amazon as a part of Amazon Web Services.	Guidance
	AWS API Gateway	Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale.	Guidance
	AWS RDS	Amazon Relational Database Service (Amazon RDS) is an easy-to-manage relational database service optimized for total cost of ownership.	Guidance
	AWS IAM	Amazon S3 is used for centralized object storage, managing all images, video, and audio across sites via public and private buckets.	Guidance
	Microsoft Bing Search	Amazon S3 is used for centralized object storage, managing all images, video, and audio across sites via public and private buckets.	Guidance
	Postman	Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster.	Guidance
	Cloudflare	Cloudflare, Inc. is an American company that provides content delivery network services, cloud cybersecurity, DDoS mitigation, wide area network services, reverse proxies, Domain Name Service, and ICANN-accredited domain registration services.	Guidance
	GitHub	GitHub is a developer platform that allows developers to create, store, manage and share their code. It uses Git software, providing the distributed version control of Git plus access control, bug tracking, software feature requests, task management, continuous integration, and wikis for every project.	Guidance
	VSCode	Visual Studio Code, also commonly referred to as VS Code, is an integrated development environment developed by Microsoft for Windows, Linux, macOS and web browsers.	Guidance
	EasyCron	EasyCron is used to run automated tasks, making API calls on a variety of schedules, using all of the APIs produced and consumed.	Guidance

Summary of this API Contract

This README is generated from the APIs.json (YAML) artifact in the root of this repository, and the properties and artifacts indexed as part of this contract. This contract is manually and automatically updated using Git, the GitHub API, and pushed out via Webhooks and business and engineering platform APIs. The goal of the API contract is to provide a combination of the API contract for the API, but also the governance and guidance that surrounds it. This contract provides everything you need to know about the API, but also what goes into a consistent and valuable API resources.

I am still working out some of the bugs of the generator for this README, but most everything above should work. I am adding more guidance, including videos. I am considering adding links to the specifications behind each area, but it is already getting pretty busy up there. I will run this generator on the other APIs.io APIs, which are in much worse shape than this one--I predict we will learn a lot in between the diff between this high bar, and how low the bar is with other APIs.