Live data from Hacker News

Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

github.com

1–10 of 87 posts

Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#1
Hey HN! We’re Richard and Alan from Integuru (https://integuru.ai). We build low-latency integrations with platforms lacking official APIs. We take custom requests and manage creation, hosting, and authentication. To automate our work, we built an open-source AI agent that reverse-engineers internal APIs to generate integration code. Here’s a demo: https://www.youtube.com/watch?v=7OJ4w5BCpQ0.

Many products need integrations with third-party services, but platforms often lack official APIs. Examples include logistics software, financial services, electronic health records (EHRs), and government websites. To build low-latency integrations, developers must reverse-engineer internal APIs, but this can get complicated. With Integuru, you can have easier access to integrations.

We started as recent college grads trying to make US income tax data accessible. We contacted banks, brokerages, payroll software, and more to request access to their APIs, but none took us seriously. We resorted to building integrations with these systems to extract documents like W-2s and 1099s. We initially used browser automation but ran into two big problems: our integrations (1) weren’t reliable due to changing UIs and (2) had slow execution speeds due to spinning up browsers and waiting for pages to load. We experimented with AI-based automation maintenance, but it didn’t solve slow speeds. So, we concluded that browser automation is useful when execution speed isn’t essential, but reverse engineering is often the only path for performant integrations.

Through reverse-engineering dozens of platforms, we noticed many internal API design patterns that LLMs could decipher. We built an agent to automate the creation of integrations. Today, Integuru can analyze a platform’s internal API designs and build an integration in minutes.

The agent mimics what a human does when reverse-engineering. Say you want to download utility bills from a utility website. You’d first use Integuru to generate a file of network requests and a file of cookies. You pair these two files with a prompt about your desired action—in this case, to download utility bills.

Integuru identifies the final request that downloads utility bills. The request URL might look like this: https://www.example.com/utility-bills?accountId=123&userId=4.... It then identifies parts of the request that depend on other requests. The example URL contains dynamic parts— accountId and userId—that usually are in the response of previous request(s). It then finds other requests whose response contains any of these and adds them to the dependency graph. The newly found request URLs might look like https://www.example.com/getAccountId, https://www.example.com/getUserId, and so on.

This process repeats until the most recently found request doesn’t depend on any other request. Integuru then traverses up the graph, starting from the requests without dependencies while converting each request into a runnable function.

Integuru supports a surprising number of use cases like downloading documents, sending money, creating virtual cards… People already use the agent to build low-latency APIs for platforms like Robinhood, transportation management systems (TMS), and more. However, the agent still has limitations due to current LLM capabilities and long-tail edge cases, but we’ve been giving each platform to the agent for the first try. When the agent does struggle, we find the generated graphs and code still helpful as references for us to complete the work manually.

The agent and all integrations are open-source under AGPL-3.0. We charge for services to (1) build custom integrations when the agent struggles or for your convenience, (2) handle hosting, and (3) manage authentication using authentication cookies from authenticated browser sessions. We charge per API call with an implementation fee for new platforms.

We’re currently working to increase the agent’s coverage and improve code generation. We will continue to iterate and want to one day allow developers to integrate with all platforms instantly.

Integuru is still an early effort. We’re passionate about automating integrations and would love your feedback!

Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs
github.com

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#4

Very cool, congratulations! Would this work for graphql APIs with introspection disabled?

Thank you! As long as the network request contains the query, it should work as expected. So yes it should work with introspection disabled graphQL APIs. Excited to see what you do with it!

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#5
Brilliant. Is the next part to monitor and autocorrect breakage when the API in scope changes unexpectedly underneath the system? This is a pain point of workflow automation systems that integrate with APIs in my experience, typically requiring a human to triage an alert (due to an unexpected external API change), pause worker queues, ship a fix, and then resume queue processing.

Love the landing page, please keep it.

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#7
This is awesome, but I'm not sure what the long-term use case for the intersection of low-latency integration and non-production-stable is? I'm saying this as someone with way more experience than I'd like to in using reverse-engineered APIs as part of production products... You inevitably run into breakages, sometimes even actively hostile platforms, which will degrade user experience as users wait for your 1day window to fix their product again.

Though I suppose if you can auto-fix and retry issues within ~1minute or so it could work?

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#8

Brilliant. Is the next part to monitor and autocorrect breakage when the API in scope changes unexpectedly underneath the system? This is a pain point of workflow automation systems that integrate with APIs in my experience, typically requiring a human to triage an alert (due to an unexpected external API change), pause worker queues, ship a fix, and then resume queue processing. Love the landing page, please keep it…

Thanks and yes that's part of the roadmap!

Currently you need to trigger the UI actions manually to generate the network requests used by Integuru. But we're planning automate the whole thing by having another agent auto-trigger the UI actions to generate the network requests first, and then have Integuru reverse-engineer the requests.

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#9
I just noticed over the weekend new Claude agreed to reverse engineer a graphql server with introspection turned off, something Im pretty sure it would have refused for ethical reasons before the new version

it kept writing scripts, i would paste the output, and it would keep going, until it was able to create its own working discount code on an actual retail website

The only issue with these kinds of things is breaking robots.txt rules and the possibility things will break without notice, and often

The use of unofficial APIs can be legally questionable [1]

[1] https://law.stackexchange.com/questions/93831/legality-of-us...

As the authors of essentially a hacking tool, I would expect at least some legal boilerplate language about not being liable

Re: Launch HN: Integuru (YC W24) – Reverse-engineer internal APIs using LLMs

#10
post #7

This is awesome, but I'm not sure what the long-term use case for the intersection of low-latency integration and non-production-stable is? I'm saying this as someone with way more experience than I'd like to in using reverse-engineered APIs as part of production products... You inevitably run into breakages, sometimes even actively hostile platforms, which will degrade user experience as users wait for your 1day win…

This is a very important question. Thank you for bringing this up! Currently it requires human intervention to auto-fix integrations as someone needs to trigger the correct network request. We are planning on having another agent that triggers the network requests through interacting with the UI and then passing the network request to Integuru.
Post reply on HN