Skip to main content

Track and review API changes as a team
Design better APIs · Improve quality · Ship faster.

Snyl

“We are set us up to provide a great API and an amazing developer experience to our consumers. Realizing the promise of OpenAPI has always been hard. Optic's tools made it easier to get developers on-board and start fulfilling the promises of working API-first.”

Gary Poster
Senior Director Of Engineering, Platform Extensibility Group

Tools to help your team adopt OpenAPI and start working API-first

Adopting OpenAPI is hard and many teams have difficultly getting started. With Optic's open source tools you will spend your time building a great API, not fighting YAML.

The API-First Checklist:

Effective API Reviews. On API-first teams every API change is reviewed before getting deployed to consumers.

Optic makes the scope and impact of proposed API changes obvious. You get to focus on the API changes, not the YAML

Use Optic CI to catch breaking changes, SLA violations and problematic designs before they reach consumers

optic compare --from main:openapi.yaml --to feature/1:openapi.yaml
Loading...

Design the API together. On API-first teams every new endpoint is designed with the consumer in mind and follows the API style-guide

Optic makes it easy to work design-first. Design your API using example JSON. When you are ready to build the API, Optic will turn the example into JSON Schema.

Don't just document your API standards, make them easy to follow. Optic helps developers rapidly fill out their OpenAPI description with operations that follow the team's standards

optic run add-search-operation --schema #/components/VenueRecord

Optic helps developers build the API as designed. Prove any set of API changes with traffic from CURL, Postman, or other sources

optic prove https://github.com acme-corp/api/pulls/55

Change the API with confidence. API-first teams are not afraid to change the API. Automated tools have their back, and catch any breaking changes in CI. Meanwhile effective API reviews help everyone discuss API changes and build the best API for the job.

Did you make an API change? Don't spend 30 mins trying to document the change in OpenAPI. Just show Optic some example traffic and it will update the spec for you. Seriously, it's like magic.

optic update --intercept 5000

Run Optic after you change the API to check your work for breaking changes. Don't worry, if you missed something it will be caught in CI.

optic compare --from main:openapi.yaml --to feature/1:openapi.yaml
Loading...

Ready to go API-first?Optic helps you make the leap

Optic is helping teams go API-first

Case Study

Snyk’s shift left approach to API development

Learn about how Snyk partnered with Optic to shift left their API development process. You can use the open source tools we built together in your own company by joining the beta

Terence Tirella - Snyk

Terence Tirella - Snyk

Storytelling

Detecting Breaking Changes Across API Versions

[Optic is helping] us be more aware of the change that is inevitable across our APIs, but done in a way that will minimize the disruption to the consumers who depend on our APIs

Kin Lane - API Evangelist

Kin Lane - API Evangelist

Release

Beyond API linting: writing rules about API changes

In practice the things API-first teams care most about are not possible to detect with linters i.e. preventing breaking changes, making their APIs consistent, and ensuring they meet their SLAs. That's why we released optic-ci

Aidan Cunniffe - Optic - Founder

Aidan Cunniffe - Optic - Founder