Why I’m building APIToolkit
APIToolkit wants to be the first thing developers think about when they’re building or working with APIs.
We want to completely solve all the problems & friction developers experience on their API lifecycle. To illustrate the lifecycle:
Design
When developers have to create an API, first they model and design it with stakeholders or intended consumers of the API.
Mocks
They might want to build a mock around that API design, so their stakeholders can already integrate it while waiting for the team to finish implementation.
Documentation
The devs build against this API specification, & likely need nice and visual documentation and a playground to test & share with stakeholders.
Tests
After building, the devs need to know if their API matches the specification,, so they write tests to validate it for the expected behavior. If It passes the tests, they deploy and release the API.
Monitoring
The API is live, but does performs as expected? What errors are the users receiving & why? Are the endpoints too slow? Is it getting slower and faster over time? What endpoints are live?
Changelog
But even more important, they need to know that the new engineering intern didnt push a harmless change with innocent assumptions, which ends up quietly breaking the API for their customers. The want to be aware of, and even approve every new change on the public APIs.
Safer Migrations
Time flies, and a need comes; they need to rewrite their API in a new tech stack & need to ensure that even with the rewrite, the endpoints remain exactly the same and their customers notice no changes.
Reports
They want regular reports that everything is working well.
Dependency Monitoring and Changelog
They integrate new APIs and need to ensure the same things for these new dependencies. They need to ensure their integrations dont get too slow, or break their app via unannounced breaking changes. That their dependency meets their SLO and promised uptime expectations.
Security
Then security becomes a topic. SQL injection, leaked secrets, best practices, linting and static analysis becomes a topic, to remove the endless arguments and meetings, and simply enforce a particular convention and standard for the APIs.
Developers worry about too many things in the lifetime of their API, and we intend to make that burden lighter so they can focus on the things that matter: “SHIPPING GREATNESS”.
