Twitter Automation Without API runs account actions through the installed X mobile app instead of sending requests to developer endpoints. The control path is a real Android or iOS device, a device driver, an account profile, and a queued action such as post, follow, like, repost, or direct message. That makes the repository useful when the job is to exercise the same mobile interface an operator already uses, while keeping API credentials and API request quotas out of the execution path.
The distinction matters because the X API is a separate product with its own access, billing, authentication, and request controls. X currently documents pay-per-use pricing, and its rate-limit reference shows endpoint-specific windows that are commonly 15 minutes or 24 hours and return HTTP 429 when exceeded. This project does not call those endpoints for account actions. It drives the app UI instead.
An API integration is the cleaner choice when the required endpoint is available, the account has suitable access, and the request volume fits the published limits. This repository covers the other case: the workflow is defined in terms of visible app actions and needs to stay independent of API credentials. The queue therefore describes intent at the UI level — open composer, enter text, submit, confirm — rather than translating every action into an HTTP request.
That changes the failure modes. There is no bearer token to expire and no API quota counter to watch, but the device can be locked, the app can show a modal, a selector can move after an app update, or the network can fail. The runner treats the device and account as a lane, serializes actions within that lane, and records the result so the next run can distinguish a completed action from one that needs operator attention. A real-device path removes API dependency; it does not remove platform rules.
| Feature | Description |
|---|---|
| Real mobile-app control | API-only workflows stop when access or endpoint limits do not fit the job. The runner controls the installed X app on Android or iOS through a real-device UI session. |
| Account actions | Manual repetition is the bottleneck. The action layer covers login, posting, following, liking, reposting, and direct messages using the same visible screens the device exposes. |
| Multiple account profiles | Keeping several accounts on one device creates session and state collisions. Account aliases map jobs to the intended session, and the device lane runs one account action sequence at a time. |
| Scheduled action queue | Bursty batches are hard to inspect and recover. Jobs carry a planned execution window, optional spacing between actions, and a deterministic order so runs can be replayed from logs. |
| Mobile proxy profiles | A device may need a defined mobile network route. Proxy profiles are assigned per lane and can rotate among configured endpoints without changing the action code. |
| ADB-optional operation | Direct ADB commands are not always part of the operator workflow. Android can use Appium-managed sessions with ADB available for diagnostics, while iOS uses its own driver path. |
| Run evidence | A tap sequence can fail without an exception. The runner writes action status, timestamps, device/account identifiers, and failure screenshots so a bad state is visible after the run. |
Every run starts with a job file. A job names the account alias, device lane, action type, action payload, proxy profile, and schedule window. The dispatcher locks that device lane before it touches the app. This prevents two queued actions from competing for the same screen or account session. The driver then brings X to the foreground, checks the expected starting screen, and hands control to the matching action module.
For a post job, the module opens the composer, fills the text, submits it, and waits for the UI to return to a known state. Follow, like, repost, and DM jobs use their own screen checks rather than assuming every tap succeeded. The finalizer writes a JSONL result record and, on a failed state, a screenshot path. Network routing is selected before the action starts. Rotation is a configured connectivity choice, not a mechanism for bypassing enforcement or disguising prohibited activity.
The orchestration layer is Python because the repository mostly coordinates jobs, configuration, device sessions, and result files. Appium is the cross-platform device-control layer: UiAutomator2 handles Android sessions and XCUITest handles iOS sessions. On Android, ADB is useful for device discovery, connectivity checks, app state inspection, and troubleshooting. The runner does not require the operator to script every action as an ADB command.
For iOS paths that use recorded touch automation, AutoTouch provides the device-side scripting surface. The repository keeps those scripts separate from Appium page objects so the queue and account model stay the same even when the execution adapter changes. YAML holds non-secret device and account aliases; secrets belong in environment variables or the host secret store. JSONL is used for run evidence because it is append-friendly and easy to inspect with command-line tools.
The layout separates orchestration from device-specific code. Action modules know what screen sequence defines a post, follow, like, repost, or DM. Driver adapters know how to reach that screen on Android or iOS. The scheduler never reaches into selectors directly; it passes a job to the selected adapter and receives a result object. That boundary is useful when the X app changes because selector maintenance does not require rewriting queue logic or account configuration.
x-real-device-runner/
├── README.md
├── pyproject.toml
├── .env.example
├── config/
│ ├── devices.yaml
│ ├── accounts.yaml
│ ├── proxies.yaml
│ └── schedule.yaml
├── src/
│ ├── cli.py
│ ├── dispatcher.py
│ ├── scheduler.py
│ ├── models.py
│ ├── actions/
│ │ ├── login.py
│ │ ├── post.py
│ │ ├── follow.py
│ │ ├── like.py
│ │ ├── repost.py
│ │ └── dm.py
│ ├── drivers/
│ │ ├── android_appium.py
│ │ ├── ios_appium.py
│ │ └── autotouch_adapter.py
│ ├── network/
│ │ └── proxy_profiles.py
│ └── evidence/
│ ├── result_writer.py
│ └── screenshots.py
├── jobs/
│ ├── example-post.yaml
│ └── example-dm.yaml
├── runs/
│ └── .gitkeep
├── ios/
│ └── autotouch/
│ └── x_actions.js
└── tests/
├── test_jobs.py
└── test_dispatcher.py
- STEP 1 — Download & Set Up the Project — Download, set up, and install Twitter Automation Without API from this repository, create the virtual environment, then install the Python dependencies and Appium drivers.
- STEP 2 — Register Devices and Accounts — Add device identifiers, platform driver, account aliases, and optional proxy profile names to the YAML config. Keep passwords and tokens outside version control.
- STEP 3 — Queue an Action — Create a job with
account,device,action,payload, andrun_at. Usepost,follow,like,repost, ordmas the action. - STEP 4 — Run and Inspect Output — Start the CLI worker. It executes due jobs, writes one JSONL result per action, and stores a failure screenshot when UI verification fails.
python -m venv .venv
source .venv/bin/activate
pip install -e .
appium driver install uiautomator2
appium driver install xcuitest
python -m src.cli run --config config --jobs jobsaccount: news_account_1
device: pixel_01
action: post
payload:
text: "Scheduled from the device queue"
proxy_profile: mobile_primary
run_at: "2026-09-03T14:30:00+02:00"The repository is useful when the required operation is already defined as an X app action rather than a data-retrieval task. It is not a general social-network crawler, analytics platform, or replacement for API-based read access. The practical fit is narrower: a known account, a known mobile device, a known action, and a queue that needs repeatable execution and evidence.
- Publish scheduled posts from an account already configured on a physical device, then verify that the composer returns to the expected post-login screen.
- Run approved engagement queues that contain follows, likes, or reposts, with one device lane serializing actions so account state does not collide.
- Send direct messages from a queued payload where the operator has already determined that the message and recipient comply with X rules and user expectations.
- Operate several account profiles on one device by mapping each queued job to an account alias and switching only when the lane is idle.
A short recorded demo shows the real-device execution concept. The important part is not the exact screen layout in the recording; mobile interfaces change. The repository is structured so selectors and device adapters can be updated without changing the job format that feeds the queue.
Real-device control is not a permission bypass. X's current automation rules state that automated activity remains subject to platform rules and warn that non-API automation can lead to enforcement, including suspension. Those rules also prohibit spam, unwanted automated messages, and attempts to manipulate the platform. Anyone running this repository is responsible for the accounts, message content, recipients, and behavior it triggers.
The technical limits are different from API limits but still real. A mobile-app update can move selectors; an authentication challenge can stop login; a locked device can invalidate the expected screen; and network changes can interrupt a session. The correct response is to stop or mark the job failed, preserve evidence, and review the state. Do not add loops whose purpose is to defeat challenges, conceal automation, or continue after an enforcement signal. Production operation also means maintaining drivers, selectors, device health, credentials, and policy checks over time.
No. The execution method does not override X's rules. The platform's published automation policy applies to automated activity and specifically warns that non-API automation may lead to account enforcement. Use the repository only for activity you are authorized to perform and that complies with current platform rules.
No for the account actions described here. Posts, follows, likes, reposts, DMs, and login are executed through the mobile app UI on a real device, so the runner does not need an X API bearer token for those actions. Any separate API-based feature you add would have its own authentication and limits.
Yes, the configuration supports multiple account profiles per device, but actions are serialized through one device lane so two accounts do not compete for the same screen. Account aliases identify the intended session, and the operator remains responsible for whether each account and automated action is permitted under X rules.
This scraper helped me gather thousands of posts effortlessly. The setup was fast, and exports are super clean and well-structured. Nathan Pennington |
What impressed me most was how accurate the extracted data is. Likes, comments, timestamps — everything aligns perfectly. Greg Jeffries |
It's by far the best tool I've used. Ideal for trend tracking, competitor monitoring, and influencer insights. Karan |