Today I released the community plugins for Voiden.

This is a big one because one of the things I dont want is the API tool to become bloated with new features - so I want to allow anyone to build plugins to grow the tool.

docs: https://docs.voiden.md/docs/plugins/build-a-plugin

Typing out a few hundred lines of code was never the real bottleneck. What was expensive was everything around it: making it correct, making it maintainable (often underestimated), coordinating across teams and supporting it long term.

You can also overshoot: Testing every possible path, validating across every platform, or routing every change through layers of organizational approval can multiply costs quickly. At some point, process (not code) becomes the dominant expense.

What LLMs clearly reduce is the short-term cost of producing working code. That part is dramatically cheaper.

The long-term effect is less clear. If we generate more code, faster, does that reduce cost or just increase the surface area we need to maintain, test, secure, and reason about later?

Historically, most of software’s cost has lived in maintenance and coordination, not in keystrokes. It will take real longitudinal data to see whether LLMs meaningfully change that, or just shift where the cost shows up.

We recently started working on a tool called Voiden and wanted to share it here to get your thoughts and feedback.

Over the years, we found ourselves managing way too many tools just to work with APIs: one for api specs, another for docs, a third for tests, etc etc. Eventually it starts to feel more like a performance than actual work.

So we built Voiden: A git-native, extensible, and lightweight client that brings everything—specs, docs, tests, mocks—into one place. No bloat, no lock-in, no "platform overhead." Just structured API workflows that don’t fight your tools or your team.

A few things we care about:

-Reusability and composability : APIs as building blocks, not silos.

-Structure over scatter : everything lives together in one workspace.

-No sign-in required : you can use it without creating an account.

Free and open — we are building this with the community in mind.

Just to be clear: The goal is NOT to replace OpenAPI, but to provide a layer around existing specs that feels coherent, hackable, and friendly to real-world dev workflows.

You can check it out here: https://voiden.md/

And if you have feedback, suggestions, or just want to follow along:

https://github.com/VoidenHQ/feedback

We are still early, but would love to hear what you think—what you like, what is missing. Appreciate any time you take to try it out.

Nikolas

Comments URL: https://news.ycombinator.com/item?id=43961565

Points: 6

# Comments: 0

At ApyHub we currently host 110+ APIs (that are available for our users to consume) + we operate hundreds of internal APIs that power the platform. With all these APIs we had/need to be super careful and diligent about API management.

We soon found out (the hard way) that the de facto API clients (even the newer, supposedly “modern” ones) did not make our lives much easier when it came to building and Testing APIs (not to mention collaboration).

So we decided to do something about it and (long story short), Fusion is the result: We like to call it the Notion-like API Client because it follows Notion’s philosophy of modularity, collaboration and extensibility.

Some points that I think are worth mentioning:

Modularity: Fusion is built with modularity from the ground up - API requests are composed of blocks - like headers, query, body, post request tests etc. Just to give some reference, in postman and other clients these are all part of ONE request. Here you can create it as part of one request and reuse them (link or clone these blocks) in other requests. It is a new way to build APIs with reusability and efficiency in mind. You can link request blocks from other API requests and override them etc. You can have a quick look here: https://assets.apyhub.com/home/test-with-fusion.mp4

Collaboration: In most API Clients I have seen collaboration is mainly around documentation and working on API collections - users cannot easily discuss and ideate around APIs. So you end up using these API clients for testing and using other tools to collaborate with your team ( slack, Jira etc.). With Fusion, you can collaborate with your team while you are testing the APIs, or documenting them or even designing them.

Fusion AI: Right now can help generate documentation from just an API request / specs, improve existing documentation and also identify when your APIs start behaving differently than what is documented. Besides that, Fusion AI allows you to create client stubs as well as generate openapi specs from an API request. We will continue to explore more use cases where AI can reduce manual efforts, increase efficiency etc.

We intend to integrate Fusion into the entire Software Development lifecycle - start from project management tools, git repos, CI/CD, and monitoring as well to make it seamless to use it from everywhere.

Fusion also supports a self hosted mode besides the cloud offering, in case organizations / teams want to ensure that data ownership is critical for them.

We welcome you to try out Fusion. We have a free tier + the ability to start a free trial.

Interactive demo: https://app.arcade.software/share/sixDw5lhT9bp0m6J0Wwr

Cheers, Nikolas

Comments URL: https://news.ycombinator.com/item?id=40426285

Points: 1

# Comments: 0

We have released some AI enabled APIs - for now for developers who can bring their own key. I am looking for people with experience in API development and testing to let me know if they find them useful (hopefully) and what use cases they can think of that would make these APIs better.

(some of them are still on early access)

thanks!

Comments URL: https://news.ycombinator.com/item?id=39286952

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=39202940

Points: 2

# Comments: 0

Mark Zuckerberg, Meta’s chief executive, has declared that 2023 will be the “year of efficiency” at his company. So far, efficiency has translated into mass layoffs.

@nikolas and I have spent the last decade working with engineering teams to build and operate SaaS products. What we observed was that our teams spent a lot of energy building small units of functionality that were needed to provide more complex business capabilities. Take for example the HTML to PDF conversion (which in turn was used to generate pdf invoices) functionality, or simple file conversions. Not to mention data related services like fetching country lists, time zones, and other services, like validating VAT, emails etc. This approach led to a lot of effort building and supporting all sorts of capabilities, instead of building what our business actually needed. Even though we used a lot of existing libraries, the work required to integrate and then support on production was significant.

To address this problem, we started using utilities offered as a service. We did some R&D and found service providers that offered currency exchange rates, or PDF conversions as a service. This did indeed relieve some of the pressure, but it resulted in different problems:

- Dealing with multiple subscriptions, with several providers that only offered one or two specific capabilities

- Each of the providers had a specific way to integrate, such as different response standards, different authentication schemes and some did not fit right into our architectural pattern

- On the compliance side, this approach led to data handling and management related questions from security auditors

Seeing that there was no one who was really trying to solve the problem space that we identified, we started ApyHub. :)

What we offer is a growing catalog of software utility APIs that can be consumed as a service by applications. That way, we aim to relieve developers from having to build the capabilities and maintain these utilities, but also reduce the integration efforts - by having uniform integration requirements: REST APIs, JSON payloads and outputs. Users can send inputs either as URLs or files, and they can access output files directly or get a URL to access them.

We want to make it easier for developers to integrate our APIs into their applications without breaking their design standards (e.g by not downloading and re-uploading the files). All utility APIs can be accessed through the tokens / credentials that the developers generate for their application.

We are launching with +35 utility APIs and are planning to grow this number in the near future. Adding more data utilities is one of our next key goals. Over time, we also want to extend and build more sophistication in terms of building workflows, bundling options and other features that will add more sophistication in the way software utilities are discovered, managed and consumed.

Some of our APIs :

-Apy Extract : Text from Webpage: https://apyhub.com/utility/extractor-webpage-text -Apy Generate: Webpage Screenshot: https://apyhub.com/utility/generate-webpage-screenshot -Apy Image Processor : Resize : https://apyhub.com/utility/image-processor-resize -Apy Generation : iCal : https://apyhub.com/utility/generator-ical

We have a free tier, including up to 2M API requests every month.

We are running a special offer for the HN community. Everyone who signs up with the APYHACKER code, will get 500K extra requests.

If you are a developer, we welcome you to try our APIs. We have a free tier + the ability to generate personal tokens that can be used in your local environment for experimentation and testing.

If you need help with anything, if you want to hang out, talk about your projects or share your insights, feel free to join our discord server.

Cheers,

Samuel and Nikolas

Comments URL: https://news.ycombinator.com/item?id=34425658

Points: 10

# Comments: 5