How a Hobby API Collection and Execution Tool is Evolving into a Product

In any startup, managing APIs across multiple services is a common challenge.

We faced three main issues:

1. Documenting APIs
2. Publishing the documentation
3. Updating it whenever APIs change

Each of these had its own set of questions: how to do it, where to do it, what tools to use, and who would take ownership.

To tackle this, our team decided to consolidate all APIs into a single repository called APIHub. Each service’s APIs were stored in a simple and consistent format:

GET | POST | PUT | DELETE | PATCH  
${baseurl}/endpoint  
{  
  "body": "if present"  
}

We named the files according to their function. Below is an example of a .l2 file for a "Leave Apply" API, along with a sidebar showing other APIs in the repository:

Improving Documentation Practices

We made it mandatory to include the corresponding .l2 file in every pull/merge request. If it wasn’t there, the request wouldn’t be approved. This simple rule increased API documentation consistency across the team.

From Documentation to Execution

We soon realized that manually testing APIs by copying URLs and payloads to tools like Postman was time-consuming. So, we built a CLI tool called Lama2.

Lama2 is a plain-text API manager optimized for Git-based collaboration.

With Lama2, you could pass a .l2 file as input, and the CLI would execute the API and show the response in the terminal:

This saved us from constant copy-pasting, but switching directories to find .l2 files was still tedious:

lovestaco@i3nux:~/apihub/feedback/fb_v3/leave$ l2 apply_leave.l2  

Taking it to VSCode

To streamline things further, we developed a VSCode extension. It came with features that made our workflow even smoother:

1. Execute .l2 files directly in the editor
2. Copy the file’s Git URL for easy sharing
3. Prettify JSON payloads
4. Generate code snippets for any language from .l2 syntax
5. Create templates for new APIs in seconds
6. Auto-completion of variables using LSP

This extension quickly became a favorite among the team, and we decided to release it on GitHub so others could benefit too.

The Next Problem: Scaling Documentation

As our APIs grew, we asked ourselves:

• Why manually document APIs for each service?
• Isn’t it time-consuming to update documentation for every change?

And that’s where the next chapter of our journey begins...
Follow me to learn what happens next in my next post.