API Solutions

I manage your API contracts based upon the top pain points you have across your API operations. API contracts are often shaped by the mix of perspectives that exist across enterprise API operations, but we also find that just focusing on a handful of solutions to your problems will gain you the most traction--select your areas of pain below to shape your API contract.

Where Is Your Pain?

Turning on each of these areas you feel pain will light up different policies below that will help provide solutions to each areas.

Alignment

There is no alignment between product and engineering when it comes to delivering APIs.

YES NO

Communication

Trouble with communication across teams producing APIs, but also with the consumers.

YES NO

Reliability

The reliability of APIs, but also delivery of new versions of APIs across lifecycle.

YES NO

Quality

The quality of APIs is low and doesn't deliver as expected when using over time.

YES NO

Onboarding

Friction when it comes to onboarding new consumers to using and integrating with APIs.

YES NO

Change

Struggle with managing and communicating change across APIs across the lifecycle.

YES NO

Discovery

Difficulty finding APIs when producing new APIs, and integrating into applications.

YES NO

Security

The security of APIs isn't as tight as it could be across teams producing APIs.

YES NO

Access

APIs are difficult to get the proper access to when consumers are applying.

YES NO

Simplicity

APIs are often complex and are not intuitive and easy for consumers to use.

YES NO

Consistency

The consistency of APIs and operations around them is all over the place.

YES NO

Legal

There are legal challenges that arise regularly around the usage of APIs.

YES NO

Revenue

You are having trouble generating new revenue streams with your digital resources.

YES NO

Provenance

There are struggles with understanding the source and history of resource evolution.

YES NO

You can craft your contract based upon where you are feeling the most pain, investing in the areas that matter the most to operations.

Contract Policies By Solution

[{"name":"Repository","slug":"repository","image":"/images/repositories.png","description":"The GitHub, GitLab, or BitBucket 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.","policies":["source-of-truth-repositories","source-of-truth-teams","source-of-truth-artifacts","source-of-truth-readme"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Onboarding","Change","Discovery","Security","Access","Simplicity","Consistency","Legal"]},{"name":"Metadata","slug":"metadata","image":"/images/meta-data.png","description":"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 of the agreement.","policies":["unique-identifiers","names","descriptions","images","tags"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Onboarding","Change","Discovery","Security","Access","Simplicity","Consistency","Legal"]},{"name":"Unique Identifiers","slug":"unique-identifiers","image":"/images/unique-identifiers.png","description":"Providing unique identifiers for API contracts, as well as the APIs that are indexed as part of a contract, providing a key reference.","tags":["Policies","3rd-Party","Producers"]},{"name":"Name","slug":"names","image":"/images/names.png","description":"Providing a clear, descriptive, and concise name for each API contract, as well as the APIs it contains, properly defining the scope.","tags":["Policies","3rd-Party","Producers"]},{"name":"Descriptions","slug":"descriptions","image":"/images/descriptions.png","description":"Providing a robust description of the API contract, as well as each API it contains, providing my context for stakeholders of the contract.","tags":["Policies","3rd-Party","Producers"]},{"name":"Images","slug":"images","image":"/images/images.png","description":"Including images as part of the metadata for your APIs helps make APIs more visible as part of portals, documentation, and other resources.","tags":["Policies","3rd-Party","Producers"]},{"name":"Tags","slug":"tags","image":"/images/tags.png","description":"Tags provide a bounded context for your APIs, providing keywords that help organize APIs by domains, and make them more discoverable.","tags":["Policies","3rd-Party","Producers"]},{"name":"Use Cases","slug":"use-cases","image":"/images/use-cases.png","description":"The who, what, how, and why of producing an API, making sure all of the known use cases are accurately described and kept up to date, then used to ensure each API is delivering what is expected with each use case.","policies":["who","what","how","why"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Quality","Onboarding","Discovery","Simplicity","Consistency"]},{"name":"Who","slug":"who","image":"/images/who.png","description":"Who is using an API, focusing on the people who will be putting an API to work in their applications.","tags":["Policies","3rd-Party","Producers"]},{"name":"What","slug":"what","image":"/images/what.png","description":"What will consumers be building with the resources and capabilities being made available via APIs.","tags":["Policies","3rd-Party","Producers"]},{"name":"How","slug":"how","image":"/images/how.png","description":"How will consumers be putting API resources and capabilities, getting into the details of programming languages and frameworks.","tags":["Policies","3rd-Party","Producers"]},{"name":"Why","slug":"why","image":"/images/why.png","description":"What are the reasons an API consumer will be putting APIs to work in their applications and integrations as part of their business.","tags":["Policies","3rd-Party","Producers"]},{"name":"Documentation","slug":"documentation","image":"/images/documentation.png","description":"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 need.","policies":["documentation-paths","documentation-request-bodies","documentation-responses","documentation-schema"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Quality","Onboarding","Discovery","Simplicity","Consistency"]},{"name":"Paths","slug":"documentation-paths","image":"/images/paths.png","description":"Providing simple, clean, and intuitive paths as part of the documentation being published for consumers to use.","tags":["Policies","3rd-Party","Producers"]},{"name":"Request Bodies","slug":"documentation-request-bodies","image":"/images/request-bodies.png","description":"Including details and examples regarding the request bodies being submitted for POST, PUT, and other possible methods.","tags":["Policies","3rd-Party","Producers"]},{"name":"Responses","slug":"documentation-responses","image":"/images/responses.png","description":"Making sure there is a complete example for each API response in documentation, including happy and unhappy responses.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema","slug":"documentation-schema","image":"/images/schema.png","description":"Documenting all of the schema which are used as part of request bodies and responses, providing JSON SChema representations of each.","tags":["Policies","3rd-Party","Producers"]},{"name":"Examples","slug":"documentation-examples","image":"/images/examples.png","description":"Providing examples of request and responses, with as many variations as possible, helping demonstrate wide usage of an API.","tags":["Policies","3rd-Party","Producers"]},{"name":"OpenAPI","slug":"openapi","image":"/images/openapi.png","description":"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 supporting elements.","policies":["openapi-version","openapi-info-title","openapi-info-description","openapi-info-contact","openapi-info-license","openapi-info-terms-of-service","openapi-info-version","openapi-path-naming","openapi-operation-methods","openapi-operation-summary","openapi-operation-description","openapi-operation-ids","openapi-operation-tags","openapi-operation-security","openapi-operation-request-bodies","openapi-operation-request-bodies-media-type","openapi-operation-request-bodies-schema","openapi-operation-parameter-in","openapi-operation-parameter-names","openapi-operation-parameter-descriptions","openapi-operation-parameter-type","openapi-operation-parameter-schema","openapi-operation-response-2xx","openapi-operation-response-2xx-media-type","openapi-operation-response-2xx-schema","openapi-operation-response-2xx-examples","openapi-operation-response-4xx","openapi-operation-response-4xx-media-type","openapi-operation-response-4xx-schema","openapi-operation-response-4xx-examples","openapi-operation-response-5xx","openapi-operation-response-5xx-media-type","openapi-operation-response-5xx-schema","openapi-operation-response-5xx-examples","openapi-schema-type","openapi-schema-naming","openapi-schema-descriptions","openapi-schema-property-names","openapi-schema-property-descriptions","openapi-schema-property-type","openapi-schema-property-enums","openapi-schema-property-required","openapi-schema-property-shapes","openapi-tags","openapi-security","openapi-components"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Quality","Onboarding","Change","Discovery","Simplicity","Consistency","Security"]},{"name":"OpenAPI Version","slug":"openapi-version","image":"/images/versions.png","description":"Requiring there is the latest version of OpenAPI available.","tags":["Policies","3rd-Party","Producers"]},{"name":"Title","slug":"openapi-info-title","image":"/images/names.png","description":"Requiring the info title property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Description","slug":"openapi-info-description","image":"/images/descriptions.png","description":"Requiring the info description property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Contact","slug":"openapi-info-contact","image":"/images/contacts.png","description":"Requiring that there is a contact included in the OpenAPI info.","tags":["Policies","3rd-Party","Producers"]},{"name":"License","slug":"openapi-info-license","image":"/images/licenses.png","description":"Requiring the info license property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"OpenAPI Terms of Service","slug":"openapi-info-terms-of-service","image":"/images/terms-of-service.png","description":"Requiring the info terms of service property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Version","slug":"openapi-info-version","image":"/images/versions.png","description":"Requiring the info version property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Path Names","slug":"openapi-path-names","image":"/images/names.png","description":"Requiring API paths meets the policy standards that are set.","tags":["Policies","3rd-Party","Producers"]},{"name":"Operation Summary","slug":"openapi-operation-summary","image":"/images/summaries.png","description":"Requiring that all operational summaries meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Operation Description","slug":"openapi-operation-description","image":"/images/descriptions.png","description":"Requiring that all operational descriptions meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Operation Ids","slug":"openapi-operation-identifiers","image":"/images/unique-identifiers.png","description":"Requiring that all operational unique identifiers meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Operation Tags","slug":"openapi-operation-tags","image":"/images/tags.png","description":"Requiring that all operational tags meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Operation Security","slug":"openapi-operation-security","image":"/images/security.png","description":"Requiring that all operational security meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Request Bodies","slug":"openapi-operation-request-bodies","image":"/images/request-bodies.png","description":"Requiring that all operational request bodies meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Request Bodies Media Types","slug":"openapi-operation-request-bodies-meda-types","image":"/images/media-types.png","description":"Requiring that all operational request body media types meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Request Bodies Schema","slug":"openapi-operation-request-bodies-schema","image":"/images/schema.png","description":"Requiring that all operational request body schema meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Parameter In","slug":"openapi-operation-parameter-in","image":"/images/parameters.png","description":"Requiring that all operational parameters in property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Parameter Names","slug":"openapi-operation-parameter-names","image":"/images/names.png","description":"Requiring that all operational parameters names meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Parameter Descriptions","slug":"openapi-operation-parameter-descriptions","image":"/images/descriptions.png","description":"Requiring that all operational parameters descriptions meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Parameter Type","slug":"openapi-operation-parameter-types","image":"/images/types.png","description":"Requiring that all operational parameters type property meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Parameter Schema","slug":"openapi-operation-parameter-schema","image":"/images/schema.png","description":"Requiring that all operational parameters schema meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 2xx","slug":"openapi-operation-response-2xx","image":"/images/200.png","description":"Requiring that all 2xx responses meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 2xx Media Type","slug":"openapi-operation-response-2xx-media-types","image":"/images/200.png","description":"Requiring that all 2xx response media types meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 2xx Schema","slug":"openapi-operation-response-2xx-schema","image":"/images/check.png","description":"Requiring that all 2xx responses schema meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 2xx Examples","slug":"openapi-operation-response-2xx-examples","image":"/images/200.png","description":"Requiring that all 2xx response examples meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 4xx","slug":"openapi-operation-response-4xx","image":"/images/400.png","description":"Requiring that all 4xx responses meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 4xx Media Type","slug":"openapi-operation-response-4xx-media-types","image":"/images/400.png","description":"Requiring that all 2xx response media types meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 4xx Schema","slug":"openapi-operation-response-4xx-schema","image":"/images/400.png","description":"Requiring that all 4xx response schema meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 4xx Examples","slug":"openapi-operation-response-4xx-examples","image":"/images/400.png","description":"Requiring that all 4xx response examples meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 5xx","slug":"openapi-operation-response-5xx","image":"/images/500.png","description":"Requiring that all 5xx responses meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 5xx Media Type","slug":"openapi-operation-response-5xx-media-types","image":"/images/500.png","description":"Requiring that all 5xx response media type meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 5xx Schema","slug":"openapi-operation-response-5xx-schema","image":"/images/500.png","description":"Requiring that all 5xx response schema meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response 5xx Examples","slug":"openapi-operation-response-5xx-examples","image":"/images/500.png","description":"Requiring that all 5xx response examples meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Type","slug":"openapi-schema-type","image":"/images/types.png","description":"Requiring that all schema type meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Names","slug":"openapi-schema-names","image":"/images/names.png","description":"Requiring that all schema names meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Descriptions","slug":"openapi-schema-descriptions","image":"/images/descriptions.png","description":"Requiring that all schema descriptions meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Names","slug":"openapi-schema-property-names","image":"/images/names.png","description":"Requiring that all schema property names meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Descriptions","slug":"openapi-schema-property-descriptions","image":"/images/descriptions.png","description":"Requiring that all schema property descriptions meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Type","slug":"openapi-schema-property-types","image":"/images/types.png","description":"Requiring that all schema property types meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Enums","slug":"openapi-schema-property-enums","image":"/images/enums.png","description":"Requiring that all schema property enums meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Required","slug":"openapi-schema-property-required","image":"/images/required.png","description":"Requiring that all schema property required meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Schema Property Shapes","slug":"openapi-schema-property-shapes","image":"/images/shapes.png","description":"Requiring that all schema property shapes meets the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"OpenAPI Tags","slug":"openapi-openapi-tags","image":"/images/tags.png","description":"Requiring that all OpenAPI tags meet the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"OpenAPI Security","slug":"openapi-openapi-security","image":"/images/security.png","description":"Requiring that OpenAPI security meet the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"OpenAPI Components","slug":"openapi-openapi-components","image":"/images/components.png","description":"Requiring that OpenAPI components meet the policy standards.","tags":["Policies","3rd-Party","Producers"]},{"name":"Getting Started","slug":"getting-started","image":"/images/getting-started.png","description":"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 language, and easy to follow.","policies":["getting-started-documentation","getting-started-authentication","getting-started-sdks"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Onboarding","Access","Simplicity","Consistency"]},{"name":"Documentation","slug":"getting-started-documentation","image":"/images/documentation.png","description":"Provide a link and description to your API documentation, providing the entry point for API consumers to begin learning about what your API does.","tags":["Policies","3rd-Party","Producers"]},{"name":"Authentication","slug":"getting-started-authentication","image":"/images/authentication.png","description":"Needs description.","tags":["Policies","3rd-Party","Producers"]},{"name":"SDKs","slug":"getting-started-sdks","image":"/images/sdks.png","description":"Provide a link and description of where API consumers can learn more about authentication and how it will work when they use an API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Login","slug":"login","image":"/images/login.png","description":"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 steps as possible.","policies":["None"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Onboarding","Access"]},{"name":"Plans","slug":"plans","image":"/images/plans.png","description":"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 the business of APIs.","policies":["plan-metrics","plan-rate-limits","plan-time-rame","plan-regions","plan-elements"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Onboarding","Access","Simplicity","Consistency"]},{"name":"Metrics","slug":"plan-metrics","image":"/images/metrics.png","description":"Providing details regarding the metrics available for each plan, outlining how the usage of digital resources and capabilities are being measured.","tags":["Policies","3rd-Party","Producers"]},{"name":"Rate Limits","slug":"plan-rate-limits","image":"/images/rate-limits.png","description":"Providing details of rate limits being applied as part of each plan, and what is available to consumers as part of their application usage.","tags":["Policies","3rd-Party","Producers"]},{"name":"Time Frame","slug":"plan-time-frame","image":"/images/time-frame.png","description":"Break down usage for for consumers based upon second, minutes, days, weeks, months, or other relevant time-frame for them to understand their usage.","tags":["Policies","3rd-Party","Producers"]},{"name":"Regions","slug":"plan-regions","image":"/images/regions.png","description":"Providing regional details available for access API resources and capabilities in different geographical regions as part of API plan usage.","tags":["Policies","3rd-Party","Producers"]},{"name":"Elements","slug":"plan-elements","image":"/images/elements.png","description":"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.","tags":["Policies","3rd-Party","Producers"]},{"name":"Authentication","slug":"authentication","image":"/images/authentication.png","description":"Distilling down the authentication required for an API, outlining API keys required, JWT, OAuth, and other authentication types, providing details on how to obtain accounts, tokens, and anything needed for accessing APIs.","policies":["authentication-keys","authentication-jwt","authentication-oauth","authentication-scopes"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Onboarding","Security","Access","Consistency"]},{"name":"Keys","slug":"authentication-keys","image":"/images/keys.png","description":"Require the API key usage meets standards set by authentication policies.","tags":["Policies","3rd-Party","Producers"]},{"name":"JWT","slug":"authentication-jwt","image":"/images/jwt.png","description":"Require JWT usage meets standards set by authentication policies.","tags":["Policies","3rd-Party","Producers"]},{"name":"OAuth","slug":"authentication-oauth","image":"/images/oauth.png","description":"Require that OAuth usage meets standards set by authentication policies.","tags":["Policies","3rd-Party","Producers"]},{"name":"Scopes","slug":"authentication-scopes","image":"/images/scopes.png","description":"Require Oauth scopes meets standards set by authentication policies.","tags":["Properties","3rd-Party"]},{"name":"Road Map","slug":"road-map","image":"/images/road-maps.png","description":"Providing a simple yet informative look at what features are being planned for future releases of an API, or even sharing that nothing is currently being planned--just providing any insight on what the future will hold.","policies":["road-map-date","road-map-title","road-map-details","road-map-version"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Change","Discovery","Consistency"]},{"name":"Date","slug":"road-map-date","image":"/images/dates.png","description":"The date for the proposed API change in the road map.","tags":["Properties","3rd-Party"]},{"name":"Title","slug":"road-map-title","image":"/images/names.png","description":"The title for the proposed API change in the road map.","tags":["Properties","3rd-Party"]},{"name":"Details","slug":"road-map-details","image":"/images/descriptions.png","description":"The description for the proposed API change in the road map.","tags":["Properties","3rd-Party"]},{"name":"Road Map Version","slug":"road-map-version","image":"/images/versions.png","description":"The version of the proposed API change in the road map.","tags":["Properties","3rd-Party"]},{"name":"Versioning","slug":"versioning","image":"/images/versions.png","description":"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 tune into communication.","policies":["versioning-semantic-versioning","versioning-date-base"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Change","Consistency"]},{"name":"Semantic Versioning","slug":"versioning-semantic-versioning","image":"/images/semantic-versioning.png","description":"Require usage of major, minor, and patch Semantic Versioning for managing change.","tags":["Properties","3rd-Party"]},{"name":"Date-Based Versioning","slug":"versioning-date-base","image":"/images/date-based-versioning.png","description":"Require usage of date-base versioning for managing change.","tags":["Properties","3rd-Party"]},{"name":"Change Log","slug":"change-log","image":"/images/change-logs.png","description":"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 has happened for an API.","policies":["change-log-date","change-log-title","change-log-details","change-log-version"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Change","Simplicity","Consistency"]},{"name":"Date","slug":"change-log-date","image":"/images/dates.png","description":"The date of the change that was made to an API.","tags":["Properties","3rd-Party"]},{"name":"Title","slug":"change-log-title","image":"/images/names.png","description":"The title of the change that was made to an API.","tags":["Properties","3rd-Party"]},{"name":"Details","slug":"change-log-details","image":"/images/descriptions.png","description":"The description of the change that was made to an API.","tags":["Properties","3rd-Party"]},{"name":"Version","slug":"change-log-version","image":"/images/versions.png","description":"The version of the change that was made to an API.","tags":["Properties","3rd-Party"]},{"name":"SDKs","slug":"sdks","image":"/images/sdks.png","description":"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 consumers of an API.","policies":["sdks-javascript","sdks-php","sdks-java","sdks-go","sdks-csharp"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Onboarding","Change","Security","Access"]},{"name":"JavaScript","slug":"sdks-javascript","image":"/images/javascript.png","description":"Require a JavaScript client SDK available with each API.","tags":["Policies","3rd-Party","Producers"]},{"name":"PHP","slug":"sdks-php","image":"/images/php.png","description":"Require a PHP client SDK available with each API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Java","slug":"sdks-java","image":"/images/java.png","description":"Require a Java client SDK available with each API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Go","slug":"sdks-go","image":"/images/go.png","description":"Require a Go client SDK available with each API.","tags":["Policies","3rd-Party","Producers"]},{"name":"CSharp","slug":"sdks-csharp","image":"/images/csharp.png","description":"Require a CSharp client SDK available with each API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Status","slug":"status","image":"/images/status.png","description":"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 trust with API consumers.","policies":["status-dashboard","status-history"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Consistency"]},{"name":"Status Dashboard","slug":"status-dashboard","image":"/images/dashboard.png","description":"Require a link to as well as results from a status dashboard for an API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Status History","slug":"status-history","image":"/images/history.png","description":"Require a link to as well as results from a status history for an API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Performance","slug":"performance","image":"/images/performance.png","description":"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 matter to API consumers.","policies":["performance-latency","performance-response-time"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Reliability","Quality","Onboarding","Consistency"]},{"name":"Latency","slug":"performance-latency","image":"/images/latency.png","description":"Requiring details regarding the regular latency for each available API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Response Time","slug":"performance-response-time","image":"/images/response-time.png","description":"Requiring details regarding the regular response time for each available API.","tags":["Policies","3rd-Party","Producers"]},{"name":"Security","slug":"security","image":"/images/security.png","description":"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 consumers.","policies":["security-authentication","security-owasp","security-testing"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Reliability","Quality","Change","Security","Access","Consistency"]},{"name":"Authentication","slug":"security-authentication","image":"/images/authentication.png","description":"Require details regarding how authentication is handled as part of API security.","tags":["Policies","3rd-Party","Producers"]},{"name":"OWASP","slug":"security-owasp-top-10","image":"/images/owasp.png","description":"Require that OWASP API security top ten has been applied as part of API security.","tags":["Policies","3rd-Party","Producers"]},{"name":"Testing","slug":"security-testing","image":"/images/security.png","description":"Require that security testing has occurred and publishing results for API security.","tags":["Policies","3rd-Party","Producers"]},{"name":"Support","slug":"support","image":"/images/support.png","description":"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 across APIs.","policies":["support-email","support-tickets","support-issues"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Change","Consistency"]},{"name":"Support Email","slug":"support-email","image":"/images/email.png","description":"Require that an API is supported using email.","tags":["Policies","3rd-Party","Producers"]},{"name":"Support Tickets","slug":"support-tickets","image":"/images/tickets.png","description":"Require that an API is supported using a ticketing system.","tags":["Policies","3rd-Party","Producers"]},{"name":"Support Issues","slug":"support-issues","image":"/images/issues.png","description":"Require that an API is supported using Git issues.","tags":["Policies","3rd-Party","Producers"]},{"name":"Feedback","slug":"feeback","image":"/images/feedback.png","description":"Encouraging API consumers to provide feedback on an API outside of support issues, cultivating a class of consumers that are willing to beta test and providing feedback that could impact the next version of an API.","policies":["feedback-email","feedback-discussions","feedback-issues"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Alignment","Communication","Reliability","Quality","Change","Simplicity","Consistency"]},{"name":"Feedback Email","slug":"feeback-email","image":"/images/email.png","description":"Require that an API allows for feedback via email.","tags":["Policies","3rd-Party","Producers"]},{"name":"Feedback Discussions","slug":"feeback-discussions","image":"/images/discussions.png","description":"Require that an API allows for feedback via discussion forum.","tags":["Policies","3rd-Party","Producers"]},{"name":"Feedback Issues","slug":"feeback-issues","image":"/images/issues.png","description":"Require that an API allows for feedback via Git issues.","tags":["Policies","3rd-Party","Producers"]},{"name":"Terms of Service","slug":"terms-of-service","image":"/images/terms-of-service.png","description":"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 consumers is covered.","policies":["None"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Change","Legal"]},{"name":"Privacy Policy","slug":"privacy-policy","image":"/images/privacy-policy.png","description":"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 putting APIs to work.","policies":["None"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Reliability","Quality","Access","Legal"]},{"name":"Licensing","slug":"licensing","image":"/images/licenses.png","description":"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 integrations.","policies":["None"],"tags":["Policies","3rd-Party","Producers"],"solutions":["Onboarding","Change","Consistency","Legal"]},{"name":"Source of Truth","slug":"source-of-truth","image":"/images/source-of-truth.png","description":"Establishing a single GitHub, GitLab, or BitBucket repository to manage the contract, providing a single source of truth when it comes to the API contract, as well as all of its properties supporting the evolution of the API at the center.","policies":["source-of-truth-repositories","source-of-truth-teams","source-of-truth-artifacts","source-of-truth-readme"],"tags":["Support","3rd-Party","Producers"]},{"name":"Repositories","slug":"source-of-truth-repositories","image":"/images/repositories.png","description":"Require each API contract possess a GitHub, GitLab, or BitBucket repository.","tags":["Policies","3rd-Party","Producers"]},{"name":"Teams","slug":"source-of-truth-teams","image":"/images/teams.png","description":"Require that API contract management is controlled using Git teams.","tags":["Policies","3rd-Party","Producers"]},{"name":"Artifacts","slug":"source-of-truth-artifacts","image":"/images/schema.png","description":"Require the APIs.json contract, OpenAPI, and other artifacts are stored in repository.","tags":["Policies","3rd-Party","Producers"]},{"name":"README","slug":"source-of-truth-readme","image":"/images/readme.png","description":"Require that each API contract repository has a dedicated README.","tags":["Policies","3rd-Party","Producers"]},{"name":"Questions","slug":"questions","image":"/images/questions.png","description":"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 an API for wider consumption.","policies":["questions-email","questions-issues"],"tags":["Support","3rd-Party","Producers"]},{"name":"Email","slug":"questions-email","image":"/images/email.png","description":"Allow for teams to ask questions and get answers via email.","tags":["Policies","3rd-Party","Producers"]},{"name":"Questions Issues","slug":"questions-issues","image":"/images/issues.png","description":"Allow for teams to ask questions and get answers via Git Issues.","tags":["Policies","3rd-Party","Producers"]},{"name":"Feedback","slug":"feedback","image":"/images/feedback.png","description":"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 and public API contracts in use.","policies":["feedback-email","feedback-issues"],"tags":["Support","3rd-Party","Producers"]},{"name":"Feedback Email","slug":"feedback-email","image":"/images/email.png","description":"Allow for teams to receive feedback on API contracts via email.","tags":["Policies","3rd-Party","Producers"]},{"name":"Feedback Issues","slug":"feedback-issues","image":"/images/issues.png","description":"Allow for teams to receive feedback on API contracts via Git issue.","tags":["Policies","3rd-Party","Producers"]},{"name":"Guidance","slug":"guidance","image":"/images/guidance.png","description":"Ensuring there is Just-in-Time API Guidance (TM) available throughout the life of an API contract, providing links to technological, business, and more policy focused guidance that helps teams producing API through their journey.","policies":["guidance-technical","guidance-business","guidance-policies","guidance-people"],"tags":["Support","3rd-Party","Producers"]},{"name":"Technical","slug":"guidance-technical","image":"/images/technical.png","description":"Provide access to technical API guidance as part of API contract support.","tags":["Policies","3rd-Party","Producers"]},{"name":"Business","slug":"guidance-business","image":"/images/business.png","description":"Provide access to business API guidance as part of API contract support.","tags":["Policies","3rd-Party","Producers"]},{"name":"policies","slug":"guidance-policies","image":"/images/policies.png","description":"Provide access to API policy guidance as part of API contract support.","tags":["Policies","3rd-Party","Producers"]},{"name":"people","slug":"guidance-people","image":"/images/people.png","description":"Provide access to people API guidance as part of API contract support.","tags":["Policies","3rd-Party","Producers"]},{"name":"Provenance","slug":"provenance","image":"/images/provenance.png","description":"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 forward and matures over time.","policies":["provenance-issues","provenance-pull-requests","provenance-reviews","provenance-certifications"],"tags":["Support","3rd-Party","Producers"]},{"name":"Issues","slug":"provenance-issues","image":"/images/issues.png","description":"Provide the provenance of an API contract using Git issues.","tags":["Policies","3rd-Party","Producers"]},{"name":"Pull Requests","slug":"provenance-pull-requests","image":"/images/pull-requests.png","description":"Provide the provenance of an API contract using Git pull requests.","tags":["Policies","3rd-Party","Producers"]},{"name":"Reviews","slug":"provenance-reviews","image":"/images/reviews.png","description":"Provide the provenance of an API contract using API governance reviews.","tags":["Policies","3rd-Party","Producers"]},{"name":"Certifications","slug":"provenance-certifications","image":"/images/certifications.png","description":"Provide the provenance of an API contract using regular certifications","tags":["Policies","3rd-Party","Producers"]},{"name":"Policies","slug":"policies","image":"/images/policies.png","description":"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 business reasoning behind them.","policies":["None"],"tags":["Support","3rd-Party","Producers"]},{"name":"Rules","slug":"rules","image":"/images/rules.png","description":"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 it are available as part of the contract.","policies":["None"],"tags":["Support","3rd-Party","Producers"]},{"name":"Guidance","slug":"guidance","image":"/images/guidance.png","description":"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 regular work to produce consistent APis.","policies":["None"],"tags":["Support","3rd-Party","Producers"]}]

These are the API policy areas that reflect where you identified pain above, providing the properties of where you start with an API contract. You can continue to refine to match what your needs are, then submit to receive more formal feedback from me about where you need the most help.

Repository

The GitHub, GitLab, or BitBucket 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.

YES NO

Repositories:

Require each API contract possess a GitHub, GitLab, or BitBucket repository.

Teams:

Require that API contract management is controlled using Git teams.

Artifacts:

Require the APIs.json contract, OpenAPI, and other artifacts are stored in repository.

README:

Require that each API contract repository has a dedicated README.

No Details

Metadata

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 of the agreement.

YES NO

Unique Identifiers:

Providing unique identifiers for API contracts, as well as the APIs that are indexed as part of a contract, providing a key reference.

Name:

Providing a clear, descriptive, and concise name for each API contract, as well as the APIs it contains, properly defining the scope.

Descriptions:

Providing a robust description of the API contract, as well as each API it contains, providing my context for stakeholders of the contract.

Images:

Including images as part of the metadata for your APIs helps make APIs more visible as part of portals, documentation, and other resources.

Tags:

Tags provide a bounded context for your APIs, providing keywords that help organize APIs by domains, and make them more discoverable.

No Details

Use Cases

The who, what, how, and why of producing an API, making sure all of the known use cases are accurately described and kept up to date, then used to ensure each API is delivering what is expected with each use case.

YES NO

Who:

Who is using an API, focusing on the people who will be putting an API to work in their applications.

What:

What will consumers be building with the resources and capabilities being made available via APIs.

How:

How will consumers be putting API resources and capabilities, getting into the details of programming languages and frameworks.

Why:

What are the reasons an API consumer will be putting APIs to work in their applications and integrations as part of their business.

No Details

Documentation

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 need.

YES NO

Paths:

Providing simple, clean, and intuitive paths as part of the documentation being published for consumers to use.

Request Bodies:

Including details and examples regarding the request bodies being submitted for POST, PUT, and other possible methods.

Responses:

Making sure there is a complete example for each API response in documentation, including happy and unhappy responses.

Schema:

Documenting all of the schema which are used as part of request bodies and responses, providing JSON SChema representations of each.

No Details

OpenAPI

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 supporting elements.

YES NO

OpenAPI Version:

Requiring there is the latest version of OpenAPI available.

Title:

Requiring the info title property meets the policy standards.

Description:

Requiring the info description property meets the policy standards.

Contact:

Requiring that there is a contact included in the OpenAPI info.

License:

Requiring the info license property meets the policy standards.

OpenAPI Terms of Service:

Requiring the info terms of service property meets the policy standards.

Version:

Requiring the info version property meets the policy standards.

Operation Summary:

Requiring that all operational summaries meets the policy standards.

Operation Description:

Requiring that all operational descriptions meets the policy standards.

Operation Tags:

Requiring that all operational tags meets the policy standards.

Operation Security:

Requiring that all operational security meets the policy standards.

Request Bodies:

Requiring that all operational request bodies meets the policy standards.

Request Bodies Schema:

Requiring that all operational request body schema meets the policy standards.

Parameter In:

Requiring that all operational parameters in property meets the policy standards.

Parameter Names:

Requiring that all operational parameters names meets the policy standards.

Parameter Descriptions:

Requiring that all operational parameters descriptions meets the policy standards.

Parameter Schema:

Requiring that all operational parameters schema meets the policy standards.

Response 2xx:

Requiring that all 2xx responses meets the policy standards.

Response 2xx Schema:

Requiring that all 2xx responses schema meets the policy standards.

Response 2xx Examples:

Requiring that all 2xx response examples meets the policy standards.

Response 4xx:

Requiring that all 4xx responses meets the policy standards.

Response 4xx Schema:

Requiring that all 4xx response schema meets the policy standards.

Response 4xx Examples:

Requiring that all 4xx response examples meets the policy standards.

Response 5xx:

Requiring that all 5xx responses meets the policy standards.

Response 5xx Schema:

Requiring that all 5xx response schema meets the policy standards.

Response 5xx Examples:

Requiring that all 5xx response examples meets the policy standards.

Schema Type:

Requiring that all schema type meets the policy standards.

Schema Descriptions:

Requiring that all schema descriptions meets the policy standards.

Schema Property Names:

Requiring that all schema property names meets the policy standards.

Schema Property Descriptions:

Requiring that all schema property descriptions meets the policy standards.

Schema Property Enums:

Requiring that all schema property enums meets the policy standards.

Schema Property Required:

Requiring that all schema property required meets the policy standards.

Schema Property Shapes:

Requiring that all schema property shapes meets the policy standards.

No Details

Getting Started

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 language, and easy to follow.

YES NO

Documentation:

Provide a link and description to your API documentation, providing the entry point for API consumers to begin learning about what your API does.

Authentication:

Needs description.

SDKs:

Provide a link and description of where API consumers can learn more about authentication and how it will work when they use an API.

No Details

Login

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 steps as possible.

YES NO

No Details

Plans

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 the business of APIs.

YES NO

Metrics:

Providing details regarding the metrics available for each plan, outlining how the usage of digital resources and capabilities are being measured.

Rate Limits:

Providing details of rate limits being applied as part of each plan, and what is available to consumers as part of their application usage.

Regions:

Providing regional details available for access API resources and capabilities in different geographical regions as part of API plan usage.

Elements:

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.

No Details

Authentication

Distilling down the authentication required for an API, outlining API keys required, JWT, OAuth, and other authentication types, providing details on how to obtain accounts, tokens, and anything needed for accessing APIs.

YES NO

Keys:

Require the API key usage meets standards set by authentication policies.

JWT:

Require JWT usage meets standards set by authentication policies.

OAuth:

Require that OAuth usage meets standards set by authentication policies.

Scopes:

Require Oauth scopes meets standards set by authentication policies.

No Details

Versioning

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 tune into communication.

YES NO

Semantic Versioning:

Require usage of major, minor, and patch Semantic Versioning for managing change.

Date-Based Versioning:

Require usage of date-base versioning for managing change.

No Details

Road Map

Providing a simple yet informative look at what features are being planned for future releases of an API, or even sharing that nothing is currently being planned--just providing any insight on what the future will hold.

YES NO

Date:

The date for the proposed API change in the road map.

Title:

The title for the proposed API change in the road map.

Details:

The description for the proposed API change in the road map.

Road Map Version:

The version of the proposed API change in the road map.

No Details

Change Log

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 has happened for an API.

YES NO

Date:

The date of the change that was made to an API.

Title:

The title of the change that was made to an API.

Details:

The description of the change that was made to an API.

Version:

The version of the change that was made to an API.

No Details

SDKs

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 consumers of an API.

YES NO

JavaScript:

Require a JavaScript client SDK available with each API.

PHP:

Require a PHP client SDK available with each API.

Java:

Require a Java client SDK available with each API.

Go:

Require a Go client SDK available with each API.

CSharp:

Require a CSharp client SDK available with each API.

No Details

Status

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 trust with API consumers.

YES NO

Status Dashboard:

Require a link to as well as results from a status dashboard for an API.

Status History:

Require a link to as well as results from a status history for an API.

No Details

Performance

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 matter to API consumers.

YES NO

Latency:

Requiring details regarding the regular latency for each available API.

Response Time:

Requiring details regarding the regular response time for each available API.

No Details

Security

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 consumers.

YES NO

Authentication:

Require details regarding how authentication is handled as part of API security.

Testing:

Require that security testing has occurred and publishing results for API security.

No Details

Support

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 across APIs.

YES NO

Support Email:

Require that an API is supported using email.

Support Tickets:

Require that an API is supported using a ticketing system.

Support Issues:

Require that an API is supported using Git issues.

No Details

Feedback

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 and public API contracts in use.

YES NO

Feedback Email:

Allow for teams to receive feedback on API contracts via email.

Feedback Issues:

Allow for teams to receive feedback on API contracts via Git issue.

No Details

Terms of Service

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 consumers is covered.

YES NO

No Details

Privacy Policy

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 putting APIs to work.

YES NO

No Details

Licensing

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 integrations.

YES NO

No Details

Policies

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 business reasoning behind them.

YES NO

No Details

Rules

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 it are available as part of the contract.

YES NO

No Details

While you may want to invest in many of the areas listed above, we recommend starting small, kicking off a contract and exploring where you might have the greatest impact with the governance of your enterprise API operations.

Contract Support

Each API Evangelist Contract comes with a base of support services by default, helping provide a platform for each API contract to exist, while making sure questions are answered, feedback is gathered, and guidance is available for teams who are producing APIs.

Source of Truth

Establishing a single GitHub, GitLab, or BitBucket repository to manage the contract, providing a single source of truth when it comes to the API contract, as well as all of its properties supporting the evolution of the API at the center.

YES NO

Questions

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 an API for wider consumption.

YES NO

Feedback

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 and public API contracts in use.

YES NO

Guidance

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 regular work to produce consistent APis.

YES NO

Provenance

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 forward and matures over time.

YES NO

Contract support services can be augmented and enhanced with strategy services, but should provide the baseline support that most teams producing APIs will need within the enterprise. API contract support services will ensure that teams don't lose their way during their API journey, and are able to move forward confidently with work producing APIs.

Contract Services

Initiate Contract

Feel free to initiate a contract for your APIs. If you are unsure of where to start, begin with a single contract and we can advise you from there. If you have question, go ahead an initiate, and we can answer your questions as we progress.

Your Name

Your Email

Your Role

Your Company

Other Info

This form will send an email directly to Kin Lane, with all of the information you've provided, and you should hear back within a day about how we can help you manage your API contract(s) across your public and private APIs.

APIs are powering your business today, and we want to make sure you have the contracts in place that keep your business moving into the future.