Open-sourced the setup we use to post tweets without paying for X's API [no promotion]
Our agency was paying for the official X API just to schedule and post tweets. That's $200/month on the Basic tier, $2,400 a year, for something that basically does a POST request on your behalf. At some point we looked at each other and asked why we were still doing this.
So we built a FastAPI backend that talks directly to X's internal GraphQL API, the same one your browser hits when you click "Tweet" on x.com. It uses your session cookies instead of API keys, spoofs browser-level TLS fingerprinting with curl_cffi, and dynamically scrapes X's JavaScript bundles on startup to stay current with their query IDs and feature flags. You deploy it on Render or Railway, point your n8n webhook at it, and you're posting tweets for basically the cost of a residential proxy.
We've been running this internally for a while and decided to open-source it: https://github.com/elnino-hub/x-automation
I want to be upfront about the tradeoffs because this is not a plug-and-play thing. Sessions can expire on you. Datacenter IPs get blocked almost immediately so you need residential proxies. X updates their TLS fingerprinting checks periodically, which means the hardcoded browser version in the code needs to be bumped when that happens. And if you're hammering it with more than 50 tweets a day, you will get your account locked. This is not a "set it and forget it" tool, it's more like something you maintain alongside your workflows.
The repo has everything you need to get it running, including a health check endpoint you can ping every 14 minutes to keep your container alive, a debug endpoint that shows you the raw X response when things break, and an IP check endpoint so you can verify your proxy is actually working. Environment setup is straightforward if you've deployed a Python app before.
The hardest part isn't the code itself. It's understanding why things break. If you don't know what a JA3 fingerprint is or why your session token expired after you changed networks, you're going to have a rough time debugging. That's kind of the gap with this whole approach to automation. The people who can run it don't need much help, and the people who want it usually need more support than a README can provide.
If anyone has questions about the setup or runs into issues getting it deployed, happy to help in the comments. And if you just want someone to handle this kind of infra for you, my agency does this stuff too, but genuinely, the repo should be enough for most technical folks here.