Good question! You can get the bearer token from the cookies in the browser. We also offer a hosted service where we handle the entire integration (authentication and hosting).

Does that imply I need to give you my username and password?

If you're using your own account, you can just use your own authentication cookies, but they do expire. If you're providing these functionalities for others' accounts and if you're ok with users logging in every time for usage, then no. If you'd prefer maintaining the log-in session for others, then unfortunately yes. I know this isn't ideal, but this is the unfortunate nature of unofficial APIs.

We feel your pain with maintenance. We have plans to handle this by using LLMs to detect response anomalies.

From our experience, reverse engineering is still less prone to breakage compared to traditional browser automation. But we definitely want to make integrations even more reliable with maintenance features.

Wouldn't something like snapshot testing from a scheduled probe be more effective and reliable than using an LLM?

Every X hours test the endpoints and validate the types and field names are consistent... If they change then trigger some kind of alerting mechanism to the user.

if the types and field names change, our parsing script should be able to detect that so it should be covered. I was talking about handling the subtle changes that are undetectable by checking field types and names

Thank you for your suggestions, and really glad to hear you're excited about Taiki! We will update the the FAQ with your suggestions — honestly, this part of the website is a bit outdated, and we will make sure to change it.

Regarding the Unofficial-APIs name, it was a really tough decision. We liked the name a lot but just thought it was a bit long. A Real pleasant surprise that you found it :)

Thank you! Integuru itself doesn't handle recaptchas and signed requests, but we have a hosted solution where we use third-party services to handle recaptchas and manually create integrations for handling signed requests.

We do not directly support APIs for mobile applications; however, if you use MITM software and get all the network requests into a .har file, Integuru should work as expected. We do not handle AppCheck ATM at the moment unfortunately.

take a look at https://xhr.dev/, a product I built to avoid bot detection challenges in the first place.

Good question. Finding the request that's responsible for the action you want will be a bit trickier for SSR, but it's still possible for most cases. It auto-generates regex (for now) to parse out needed info out of the html template.

Another thing I've seen is that some of these old school apps are sending certain requests that don't modify the page but set server side context which subsequent requests are dependent on.

For example, set context to a particular group and then subsequent navigation depends is filtered on that group even though the filter is not explicit on the client side but due to state stored in the session remotely.

This can also have implications on concurrency for a given session where you need to either create separate sessions or make sure there is some lock on particular parts of server side state.

Would this type of this eventually be possible? Or at least hooks in able for us to add custom code such as session locks

Very interesting to hear about your experience here! We haven't come across a website that has this design and don't offer support for this just yet. We can certainly implement if more people face a similar situation.

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.

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.

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!