Show HN: Poozle – open-source Plaid for LLMs (github.com)
Poozle (https://github.com/poozlehq/poozle) provides a single API that helps businesses achieve accurate LLM responses by providing real-time customer data from different SAAS tools (e.g Notion, Salesforce, Jira, Shopify, Google Ads etc).
Why we built Poozle: As we were talking to more AI companies who need to integrate with their customers’ data we realised managing all SAAS tools data and keeping them up-to-date is a huge infra of ETL, Auth management, Webhooks and many more things before you take it to production. It struck us – why not streamline this process and allow companies to prioritise their core product?
How it works: Poozle makes user authorization seamless using our drop-in component (Poozle Link) and handles both API Key and OAuth dance. Post-authentication developers can use our Unified model to fetch data to their LLMs (no need to sync data separately and then normalise at your end). Poozle keeps data updated in real time while giving you options to choose sync intervals. Even if the source doesn’t support webhooks, we’ve got you covered.
Currently, we support Unified API for 3 categories - Ticketing, Documentation and Email. You can watch a demo of Poozle (https://www.loom.com/share/30650e4d1fac41e3a7debc212b1c7c2d)...
We just got started a month ago and we’re eager to get feedback and keep building. Let us know what you think in the comments : )
43 comments
[ 3.8 ms ] story [ 108 ms ] threadhttps://github.com/ShishirPatil/gorilla feels like a project with certain similarities here. How would you compare yourselves to them?
More than a similarity we thought we could use the gorilla LLM knowledge to get to a more generic Unified API from different SAAS tools.
We built an in-house tool (https://www.loom.com/share/ff88f482765d43e49aebcefd3f00df27) which has all REST APIs trained. We will use this for both discoverability of APIs and also to get to a perfect Unified API personal to the companies.
Not at all commonly used in NZ. I've lived in NZ my whole life and never heard the word.
How do you deal with subtle differences in usage of terminology? If one service uses the word "ticket" slightly differently than others, how do you deal with that?
1. Dealing with custom fields. We provide a way you can map the custom fields specific to the company into the common Model.
2. Dealing with the naming difference Github has issues and Asana has Tasks. We map both the data into a common Ticket model.
This ensures that you integrate with our Ticketing Model and you are integrated to all the Ticketing platforms we support
I think, looking at this, I'd still probably prefer to create something custom. What would really help is simplifying having to set up OAuth and api calls, and just being able to do the mapping (or transform, of extract-transform-load) myself, in case there are edge-cases.
We do the ETL in the background and ensure that the model is completed irrespective of the 1-1 or different entity. You would also be doing the same if you manage the ETL. You could check (https://github.com/poozlehq/poozle/tree/main/integrations/ti...) our ticketing integrations, would love to take some feedback there.
Also if you need more customization you can write on top of the integration we have already (https://github.com/poozlehq/poozle/tree/main/integrations/ti...) and plug it into the platform.
We have a raw field from which you can pick anything integration specific.
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.
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.
You created a single API for several services.
That's where the comparison with Plaid ends.
And choosing LLMs as our primary ICP, the solution will evolve more for their needs.
Another question would be how does the schema update if say a new feature gets added to "tickets"
We are having versioning for the models and also for integrations thus giving us the flexibility to manage the schema updates
Speaking of Plaid, would love to see an integration there for personal finance
Also what kind of SAAS sources are currently ingesting?
I’m an AI researcher, so am a little further from this area, but am very curious.
1. We think the context you want is distributed into multiple APIs in most of cases and there are also multiple APIs on which you might want to search. Ex: Users, Tickets, Comments etc. A lot to build from scratch.
2. Addressing these for multiple SAAS tools means learning multiple APIs and writing different code for every SAAS tool.
3. Last but difficult is to keep all of this more real-time and build the whole tech around with webhooks to keep this real-time. Also, some SAAS tools like Notion don't have webhooks