Why APIToolkit
A few years ago, I was a new hire at a food delivery company, migrating a legacy service from PHP to Golang. We implemented the fields listed in the swagger docs, and compared the responses from the legacy service to the responses of the new service, fixing differences until everything matched.
After weeks of implementation and testing, we rolled out the new service after running tests to make sure everything worked as expected. But immediately we looked at our order monitoring charts, we knew we had messed up. Within 10mins, 20k orders lost. I was terrified. What happened?
Apparently in a couple countries we ran in, a particular field which was expected by the apps was no longer being sent, prevent placing of orders. We had no idea since this field was not in the inherited documentation, and was only applicable in a couple countries which were not part of the samples we manually tested.
We rolled back and fixed the issue, but I was sad that there was no tool which could have detected this issue faster.
Years later, this is that tool, and we would love to listen to similar stories you’ve experienced, and help make such stories a thing of the past.
Anthony (@tonialaribe) and Smile(@smilecs)
APIToolkit is built by real engineers to solve problems that have cost them a lot in the past.
We’re engineers at our core, who are very close to the problems we are solving. So, we encourage our users to be a part of this community evolving solutions to solve API documentation, management and observability.
You can do this by joining our Discord channel to join others who are part of our journey in evolving APIToolkit or book a slot to have an open conversation with us. We’re always open to have a chat with everyone and learn about their experiences around API documentation and observability.