Optic Cloud was built to make the lives of API Program teams easier. We partnered with API programs that interface with between 20-150 API teams across their organizations. We listened to their challenges and built solutions to help manage an API program at scale.
Instantly deploy and change API Standards
Problem: Getting your API linters and other tools to run in every team's CI pipelines can be a huge bottleneck. Coordinating with each team's CI engineers can be expensive and time-consuming. If you ever want to change the standards or tooling you may have to do all that work again.
Solution: Optic Cloud lets your team configure the API Standards for each team from a central dashboard. You do not need to add any code to the repositories or write any CI tasks. It just works.
- Optic listens to your GitHub/GitLab webhooks (like a CI provider)
- When OpenAPI files change, it pulls the specs from Git[Hub/Lab]'s API. We do not clone the repos for security reasons, we only look at specs.
- Optic runs your linting/diff checks on our infrastructure, then posts back via the Checks API.
Don't get in the way
Problem: API Programs know that it is important for them to not get in the way of developer productivity. Many are afraid to add automate more of their API Standards because they do not want CI to suddenly start failing for one team.
Forwards-only governance. Optic lets you write API standards that apply only to what is being
addedto your OpenAPI spec. These standards apply to new APIs, while legacy APIs will be exempted. These keeps the signal/noise ratio really high.
One engineer reported:
"Our old API linter was not useful. There were 100s of warnings so nobody understood what could be ignored, and what to fix. The new Optic stuff is great. There's no noise. Everyone pays attention"
Inform, but do not block.. Optic Cloud lets you toggle blocking CI on/off for certain APIs. Meet teams where they are, and give them the level of flexibility they need to deliver.
Exemptions. Optic Cloud lets you grant exemptions to rule failures. If one rule fails and you exempt it, CI will be set to
Make API-Reviews Effective
Problem: It is very difficult for developers to read and effectively review OpenAPI changes. Git diffs just do not cute it when it comes to APIs.
Solution: Optic automatically adds a visual API changelog to every Pull Request. Teams that use these changelogs in their reviews report much better conversations. Within a few weeks the API developers learn how to build the right API, the first time.
See all the changes in one place
Problem: When APIs are spread out across dozens of repositories, it can be very difficult to know what APIs are being designed or changed at any given time. Some teams try using CodeOwners, but that has its own challenges and still excludes product teams who do not live on GitHub from the conversations about APIs
Solution: Optic indexes all your open Pull Requests and shows you the ones that include OpenAPI changes on a single dashboard. You can filter your view further to show you only important changes you want to weigh in on ie PRs that include new endpoints, breaking changes, etc.
On the roadmap
- Searchable API directory
- Allow teams to subscribe to each other's API changes
- Full API lifecycle management -- each API Change is tagged designed, implemented, published (to environments). Optic adjusts those tags as you develop, and computes your production specification as code ships.