harshithmul

Would love to understand why you think so?

There are 3 major challenges

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

We took the first/3rd meanings https://www.wordhippo.com/what-is/another-word-for/poozle.ht... but missed in between :(

Would love to understand if there is something missing.

Gotcha. We will surely rethink on the name

Yeah we will be opensourcing this in the coming week. Happy to answer questions. Feel free to join our Slack we can discuss this there or shoot me an email at harshith[@]poozle.dev

Yeah :( looks like we should change the name

As we currently expose the common models APIs and you can use certain transformations before you send them into the VectorDB. This way you just have to write one transformation for all the SAAS tools in a specific category.

We are having versioning for the models and also for integrations thus giving us the flexibility to manage the schema updates

Got it. We might have to think to change the name

Yeah true. We will pull all similar tickets from multiple SAAS tools and send them back in a common ticketing model

gotcha.

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.

> If one service's entity has X field, but all the others don't, do you include it or not?

We have a raw field from which you can pick anything integration specific.

Yeah, I think we have 2 things here. Take an example model a "Ticket".

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

It's most commonly used in NZ. It means to scavenge for collectable objects. But yeah that's the start but later we realised it was also something else.

We are more into unified API with the right tooling needed for LLMs to talk to these SAAS tools whereas Gorilla is a model which has knowledge about APIs.

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.

Hey yeah we were working on it but after some user research, we think there is a lot of friction and not much of market there.

We are pivoting to something new and we are evaluating these.