|
|
|
|
|
by haxton
1030 days ago
|
|
Definitely a difficult problem you're taking on here, but I don't see anything specific to LLMs here? How or why are you marketing towards LLMs? How do you compare to the larger players here already Nango[0] and Merge[1] ? I'm curious how you're thinking about data access / staleness? It's great that you're handling the oauth dance, but does that mean every end user of the product has to auth every product they interface with or are you handling this all at the super admin / enterprise level? Right now I think there's too much emphasis on the "data loading" aspect of LLMs. I expect to see a swing back into using 3rd party API's SDKs. Interested to hear your thoughts on the Google API, it's absolutely massive and trying to shoehorn that into a unified API scares me. The only real player that I could see to launch something like this and be successful is Okta. [0] - https://github.com/NangoHQ/nango
[1] - https://merge.dev/ |
|
<Why LLMs> Our goal is to provide context for LLMs. Our first step is to normalize data and offload syncing, similar to other Unified API providers like Merge. In the future, we also plan to assist with vector embeddings or storing data directly in Vector DB for a search context API. We are exploring the best solution and believe building in the community will be a big help.
<Competition with large Players> Nango doesn't offer a pre-built Unified API. Merge focuses on B2B SAAS companies looking to build customer-facing integrations. Our goal is to develop tools and infrastructure to support LLMs. This is similar to how Plaid bet on the Fintech industry and built infrastructure and tools around it, starting with a Unified API for banking data.