To everyone criticizing this project, you should probably dig a bit to find out what's the context of this project.
From the integuru page:
> We build integrations with platforms lacking official APIs. We specialize in low-latency integrations via reverse-engineering. All integrations are open-source.
So these warnings are probably wasted on someone that is very much aware of what he is doing.
I looked at the website before commenting just to be sure. Judging from the quality of the design (which, yes, I think is an appropriate way to arrive at this conclusion), I would not be surprised to find out that this is a couple recent college grads who don’t realize what this business entails.
> I would not be surprised to find out that this is a couple recent college grads who don’t realize what this business entails.
It's made by Y-combinator backed startup Taiki. The cofounders (who have names similar to the ones that made commits in the git repo) seem to be pretty experienced (Alibaba, and Amazon)[0]
Those simple, minimal css websites are trendy right now as a way to signal "this isn't a bloated business, we're practical and efficient". See ssi.inc for a high profile example
If this is indeed like Plaid, a simple clause in the README would put a lot of people at ease (I looked carefully for this before making my comment): This Unofficial API was built with the express written consent of Venmo (or whatever their LLC is called).
It’s an easy thing to add to the README if it’s true. But if it’s not, that’s a problem.
Mind providing a link so I can validate this? Plaid might have API providers' permission now, but did they at the start? I forgot to mention that I was talking about when Plaid first started.
Plaid use screen scraping which is why it breaks all the time. In terms of reverse engineering undocumented but official APIs, you’re thinking of their competitor Teller.
I was under the impression that they've built up much warmer relationships on the financial account side and correspondingly have more reliable integrations than they used to.
I've personally noticed it tends to break a lot less than it used to.
they can try to justify it all they want, using these apis still breaks multiple federal laws
i noted this in a previous thread with them, to which they replied if its your data you can access it which ever way you like. Which is like saying i can hack into my bankers computer remotely to view my account balance. Which is still illegal.
Using unapproved apis is unauthorized access to a computer or network, illegal in the US at least, which ever way you want to try and look at it
Remember both Plaid and Aaron Swartz did this, it can end if very different ways. Obviously the government can pick and choose who to send to jail, but that’s a risk
If someone with millions or billions of dollars doesn’t have an official API after operating for years, that’s because they don’t want to have one. You may receive a Cease and Desist letter, or they might block your IPs, or just scramble their markup in ways that are hard to figure out. Whatever their approach, they likely have more money and manpower to throw at stopping you than you have to evade them, especially if you’re doing this to multiple large and powerful companies.
This is legal. See Teller API. Venmo will most likely lose if they take these devs to court based on precedent.
I don't like this trend of small time OSS devs being berated about legal bullying from megacorps, meanwhile handsomely VC-funded businesses get congratulated with legal help. We should be berating these companies of not releasing the APIs that people want to use!
We're in an age of AI, built atop agents, agents built atop APIs. APIs were the promise of Web 2.0, a promise being ripped away from us more and more by the day by these megacorps.
There should be a SPECIFIC legal funds/OSS unions protecting these Adversarial Interoperability projects and their maintainers from legal threat harassment by megacorps.
Just in the last 2 years we've had multiple near/passed-trillion dollar companies sending legal threats to OSS devs who have to fight them off on their own - one of them 15 years old.
Thank you alanalanlu and richardyhz for this project. Godspeed! And screw Venmo if they dare go after these two maintainers and their project!
The first time I had the plug pulled on a public API a product I worked on used sucked pretty bad. At this point its happened to me so many times that its just another line item of business risks thats an inevitability. I've never worked at a company that failed to recover as a result. Then again, I've never worked at a company whose entire business hinged on one single API.
The likelihood of things breaking or behaving in unexpected ways are data points I think about when assessing risk irrespective of whether an API is public or not. In some industries even the public APIs are more risky than using the unofficial Venmo API likely is.
It's a third-party client making authentication and data collection requests, just like the hundreds of other credential stuffing toolkits (OpenBullet et al.) that are smashing the Venmo platform 24/7.
The most likely outcome for anyone using this is their account becoming restricted for unusual access patterns by the existing models already in place.
I'd also be a bit worried about using something like this in production, especially if it's packaged as a npm lib. Even if the original maintainer has good intentions, it'd be all too easy for some malicious actor to offer them a million dollars to introduce a trojan/credential MITM scraper to later versions.
Can confirm. Plaid continues to work this way as well for many banks.
I have heard from someone who worked there that (allegedly) one of the banks had a huge PI leak that was exposed to Plaid customers and (allegedly) nothing was done because Plaid didn't want to disclose their unofficial use.
We can handle 2FA during login. Regarding refreshing auth, it depends on the platform. We can help remain logged in nearly indefinitely on some platforms, while others would require users to re-login periodically.
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).
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.
The negativity is shocking. This is HACKER News. Elegant workarounds of limitations are usually celebrated.
IMO, this should be standard procedure. If you don't want to provide the means to build greater things off of your product, expect that others will. It's a bit ironic, given that they're using open source libraries to build their product.
This is how you see spammers, scammers and grifters target people with fake bots on most platforms and the producer i.e. Venmo traces it to an SDK and will kill all these unofficial API consumers.
And once captchas are introduced it's over, I wouldn't be surprised if stuff like captchas would be implemented more into websites to stop scrapers for good.
>And once captchas are introduced it's over. I wouldn't be surprised if stuff like captchas would be implemented more into websites to stop scrapers for good.
lol, not really. Captcha solving services like DeathByCaptcha and AntiCaptcha cost like $1.90 per 1,000 successfully solved captchas. They have APIs and you can easily implement them into your existing code in a few lines.
tl;dr = captchas do nothing and they also do nothing to stop scrapers. its a non-issue.
source: I scrape a lot of things and defeat captchas daily.
To everyone criticizing this project, you should probably dig a bit to find out what's the context of this project.
From the integuru page:
> We build integrations with platforms lacking official APIs. We specialize in low-latency integrations via reverse-engineering. All integrations are open-source.
So these warnings are probably wasted on someone that is very much aware of what he is doing.
I looked at the website before commenting just to be sure. Judging from the quality of the design (which, yes, I think is an appropriate way to arrive at this conclusion), I would not be surprised to find out that this is a couple recent college grads who don’t realize what this business entails.
> I would not be surprised to find out that this is a couple recent college grads who don’t realize what this business entails.
It's made by Y-combinator backed startup Taiki. The cofounders (who have names similar to the ones that made commits in the git repo) seem to be pretty experienced (Alibaba, and Amazon)[0]
[0] https://www.taiki.ai/about-us
> Judging from the quality of the design
Half of the respected users in this forum have websites like that.
Those simple, minimal css websites are trendy right now as a way to signal "this isn't a bloated business, we're practical and efficient". See ssi.inc for a high profile example
They claim it's a project by these people, who are YC-backed: https://www.taiki.ai/
> which, yes, I think is an appropriate way to arrive at this conclusion
it's not
Indeed. It also seems more like Plaid than ElcomSoft.
If this is indeed like Plaid, a simple clause in the README would put a lot of people at ease (I looked carefully for this before making my comment): This Unofficial API was built with the express written consent of Venmo (or whatever their LLC is called).
It’s an easy thing to add to the README if it’s true. But if it’s not, that’s a problem.
Mind providing a link so I can validate this? Plaid might have API providers' permission now, but did they at the start? I forgot to mention that I was talking about when Plaid first started.
Plaid use screen scraping which is why it breaks all the time. In terms of reverse engineering undocumented but official APIs, you’re thinking of their competitor Teller.
I was under the impression that they've built up much warmer relationships on the financial account side and correspondingly have more reliable integrations than they used to.
I've personally noticed it tends to break a lot less than it used to.
They have better integration with some banks, one which goes through an OAuth flow.
they can try to justify it all they want, using these apis still breaks multiple federal laws
i noted this in a previous thread with them, to which they replied if its your data you can access it which ever way you like. Which is like saying i can hack into my bankers computer remotely to view my account balance. Which is still illegal.
Using unapproved apis is unauthorized access to a computer or network, illegal in the US at least, which ever way you want to try and look at it
Remember both Plaid and Aaron Swartz did this, it can end if very different ways. Obviously the government can pick and choose who to send to jail, but that’s a risk
It's okay to break unjust laws.
TIL Venmo uses GraphQL.
It's interesting to note, too, that the current Venmo website posts to https://account.venmo.com/api/eligibility to get a token and then separately to https://account.venmo.com/api/payments to perform the actual payment. Those endpoints and shapes are different than what's in the script, which posts to https://api.venmo.com/v1/payments (https://github.com/Integuru-AI/Venmo-Unofficial-API/blob/a28...). I wonder if the v1 API is an older one used for some other service (the mobile app, maybe?).
Thanks for sharing, OP.
This will not end well.
If someone with millions or billions of dollars doesn’t have an official API after operating for years, that’s because they don’t want to have one. You may receive a Cease and Desist letter, or they might block your IPs, or just scramble their markup in ways that are hard to figure out. Whatever their approach, they likely have more money and manpower to throw at stopping you than you have to evade them, especially if you’re doing this to multiple large and powerful companies.
This is legal. See Teller API. Venmo will most likely lose if they take these devs to court based on precedent.
I don't like this trend of small time OSS devs being berated about legal bullying from megacorps, meanwhile handsomely VC-funded businesses get congratulated with legal help. We should be berating these companies of not releasing the APIs that people want to use!
We're in an age of AI, built atop agents, agents built atop APIs. APIs were the promise of Web 2.0, a promise being ripped away from us more and more by the day by these megacorps.
There should be a SPECIFIC legal funds/OSS unions protecting these Adversarial Interoperability projects and their maintainers from legal threat harassment by megacorps.
Just in the last 2 years we've had multiple near/passed-trillion dollar companies sending legal threats to OSS devs who have to fight them off on their own - one of them 15 years old.
Thank you alanalanlu and richardyhz for this project. Godspeed! And screw Venmo if they dare go after these two maintainers and their project!
Unfortunately it's all fun until Integruru or you get a cease and desist.
Will Integruru support you in your legal fight in court?
Most devs aren't ready to lawyer up.
You get a cease and desist letter, you cease and desist doing the stuff if you don't want / can't afford a legal fight.
Then you post the cease and desist letter on your website, and post about it on hacker news.
And everyone using the API will break.
Very risky business.
The first time I had the plug pulled on a public API a product I worked on used sucked pretty bad. At this point its happened to me so many times that its just another line item of business risks thats an inevitability. I've never worked at a company that failed to recover as a result. Then again, I've never worked at a company whose entire business hinged on one single API.
The likelihood of things breaking or behaving in unexpected ways are data points I think about when assessing risk irrespective of whether an API is public or not. In some industries even the public APIs are more risky than using the unofficial Venmo API likely is.
I'd be surprised if this was even noticed at all.
It's a third-party client making authentication and data collection requests, just like the hundreds of other credential stuffing toolkits (OpenBullet et al.) that are smashing the Venmo platform 24/7.
The most likely outcome for anyone using this is their account becoming restricted for unusual access patterns by the existing models already in place.
I'd also be a bit worried about using something like this in production, especially if it's packaged as a npm lib. Even if the original maintainer has good intentions, it'd be all too easy for some malicious actor to offer them a million dollars to introduce a trojan/credential MITM scraper to later versions.
Fintech and unofficial API are two things I wouldn’t consider using at best and at worst extremely risky and possibly can get you into trouble .
How do you think Plaid worked before banks got onboard with OAuth?
Can confirm. Plaid continues to work this way as well for many banks.
I have heard from someone who worked there that (allegedly) one of the banks had a huge PI leak that was exposed to Plaid customers and (allegedly) nothing was done because Plaid didn't want to disclose their unofficial use.
Former Venmo here.
PayPal Legal is going to love this
Former guy who used to reverse engineer Venmo/ other fintech/ bank APIs here. They really don’t care most of the time
Maybe this time unfortunately.
What happens if they require 2FA via SMS or an Authenticator app to log in? Can you indefinitely refresh auth?
We can handle 2FA during login. Regarding refreshing auth, it depends on the platform. We can help remain logged in nearly indefinitely on some platforms, while others would require users to re-login periodically.
Where would I be able to learn more about how you handle this?
Feel free to book a call with us here: https://calendly.com/d/ckp6-9yn-pnd/chat-w-richard-alan
Look awesome! How do you get a bearer token? And did you look into authing transactions for other users?
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.
works until it doesn't
The negativity is shocking. This is HACKER News. Elegant workarounds of limitations are usually celebrated.
IMO, this should be standard procedure. If you don't want to provide the means to build greater things off of your product, expect that others will. It's a bit ironic, given that they're using open source libraries to build their product.
Strong +1.
There’s no need to offer bad unsolicited legal advice on behalf of a mega corp. Just stop.
This is actually dangerous.
This is how you see spammers, scammers and grifters target people with fake bots on most platforms and the producer i.e. Venmo traces it to an SDK and will kill all these unofficial API consumers.
And once captchas are introduced it's over, I wouldn't be surprised if stuff like captchas would be implemented more into websites to stop scrapers for good.
>And once captchas are introduced it's over. I wouldn't be surprised if stuff like captchas would be implemented more into websites to stop scrapers for good.
lol, not really. Captcha solving services like DeathByCaptcha and AntiCaptcha cost like $1.90 per 1,000 successfully solved captchas. They have APIs and you can easily implement them into your existing code in a few lines.
tl;dr = captchas do nothing and they also do nothing to stop scrapers. its a non-issue.
source: I scrape a lot of things and defeat captchas daily.
Goody idea in 2014 but it is 2024 and AI capabilities defeat nearly all "Prove you are a human" challenges.
> ...AI capabilities defeat nearly all "Prove you are a human" challenges
Not really, seeing lots of captchas from Arkose, Cloudflare, HCaptcha, etc keep up with this in stopping bots.