top | item 37181968

(no title)

haxton | 2 years 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/

discuss

order

Manik_agg|2 years ago

Hey I'm one of the co-founders of Poozle. Thanks for asking great questions let me take them one by one

<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.

dudus|2 years ago

I don't think the comparison to Plaid is helping as much as you think. You and Plaid are in completely different verticals and as a result have completely different goals and users.

You created a single API for several services.

That's where the comparison with Plaid ends.

Manik_agg|2 years ago

<Data Access/Staleness>

Currently every user of the product has to do the auth. However in future for our enterprise customers, we plan to support SSO and SAML.

<Google API> You're absolutely right, the array of Google APIs is vast. However, if we approach it from a category perspective, there are typically a couple of key APIs that we need to manage for instance in documentation category we take google docs and for Email we take gmail APIs.

willio58|2 years ago

It’s odd to me that people are downvoting you for clearly answering the question.