If you are here, you probably have tried a lot of tools like OpenAPI, Stoplight, and Postman. You may have tried to put into practice good ideas like working "design-first". For many reasons, these tools did not solve your problems, or they asked too much of the developers on your team, limiting adoption.
We have always acknowledged the importance of meeting teams where they are while giving them tools to improve the way they work. Our open source project took design cues from Git and the Pull Request workflow developers use every day.
With Optic, tracking new API endpoints and changes to existing ones is as easy as checking in your code. It takes 2 minutes, and many developers who did not tracktrack - Tracking a change involves using evidence of behavior change to create a proposal. Evidence is gathered from real traffic, such as from live environments or the Optic Capture Toolkit. Tracking changes is common in code-first workflows. API changes in OpenAPI do track their changes with Optic. All they have to do is show Optic some examples of their change using real traffic, and Optic helps them patch the API specificationspecification - The current API specification, and a full history of every change ever made to the API..
Optic makes reviewing API changes easy by attaching an accurate API changelog to Pull Requests that change the API. Git tells you which files change, Optic tells you which APIs change. You'll see green highlights for things that were added, yellow for those that were changed, and red for removals.
Plan changes "design-first" when you want to, have confidence the implementation will get built as designed. You can planplan - Planning a change involves defining the behavior of desired API changes for review in a proposal. The behavior desired can be defined with structured text such as OpenAPI, interactive edits to requests and responses, or structured data such as example JSON request and response bodies. Planning a change is the first step in design-first workflows. API changes, get feedback from stakeholders, and iterate before writing a line of code. When it comes time to implement the API, Optic guides developers towards implementing it correctly and certifies the work when completed.
Optic connects the API lifecycle to reality. It knows what versionversion - Defined behavioral expectations for an endpoint or API at a point in time. Once a proposal is approved, it becomes the next version of your affected endpoints. of each API is running in staging, production, etc. And it links API changes to the code changes that caused them. Because Optic grounds your specification in reality, it's easy to generate different OpenAPI documents for every environment or use
api blame to figure out where in the code an API change was introduced.
These are big claims. If you agree these ideas are the missing pieces that might help your team work better together, go explore our documentation and decide for yourself if we're approaching the problem in a way that could work for your team:
Read the docs
- Track a new endpoint
- Review API changes
- Plan a change ("design-first")
- Connect your API lifecycle to reality with Evidence
Read the blog
Updated 4 months ago
Ready to try Optic? Learn how to add your API to the tool and invite the team