Account Warmer Docs
Setup, safety, and scheduling for the desktop app. This page matches the current desktop build behavior.
Account Warmer
Account Warmer is the desktop app that runs the warming sessions and profile automation locally on your machine.
- Windows PC (the Windows build is compiled with Visual Studio / MSVC).
- Microsoft Visual C++ Redistributable (x64, Visual Studio 2015–2022).
- An anti-detect browser provider + profiles (selected inside the app).
Requirements
- An anti-detect browser account and profiles inside that provider (you select the provider in app settings).
- The provider’s desktop client running if it uses a local API (example: MoreLogin).
- Proxies configured on your browser profiles (the app can verify exit IP and help avoid reuse).
Settings (Anti-Detect Browser)
Open the Settings page and pick your Anti-Detect Browser. The selection controls which API the app uses when you open/close profiles, run proxy checks, and start warming.
Use Max concurrent warmings to control how many sessions can run in parallel (1–5). If you want the most stable behavior across many profiles, start with 1–2 and scale up slowly.
Profiles Page (Right Click)
The Profiles page is your main control surface. Select one or more profiles, then right-click to open the actions menu.
- Open Browser(s) opens the selected profiles in your chosen provider.
- Close Browser(s) closes the selected profiles in your chosen provider.
- Check Proxy (single profile only) opens the browser headless, checks the effective exit IP, shows the result, then closes the browser automatically.
- Start Warming opens the warming configuration dialog, saves those settings to the selected profiles, then starts warming.
- Configure Warming saves warming settings to the selected profiles without starting a run.
- Stop Warming stops all current warming runs.
- Create Schedule(s) creates schedules for one profile or in bulk for multiple profiles.
- Edit Profile opens the edit dialog for that profile.
- Assign Address saves a selected address into that profile’s config (addressId + addressDetails). If “Add Address During Warming” is enabled, the engine can use this address data to add it on Amazon.
- Profile Settings stores periodic check preferences (orders/messages + interval) in the profile config for future automation. The current build does not automatically run these checks yet.
- Check Status (single profile) queries browser status.
- Refresh Fingerprint(s) refreshes fingerprints for selected profiles.
- Clear Cache (single profile) clears profile cache.
Delete Profile(s) deletes selected profiles in the active provider (with a confirmation prompt).
Health Checks (Orders / Basket)
On the Profiles page there’s a quick-actions panel (Account Health) that runs “health” checks for the selected profile. These checks open the browser headless, do the check, then close the browser automatically.
Opens the profile, navigates to the Amazon order history page for the profile’s configured region, and extracts recent orders. Results are stored per profile in profiles/<profileId>/order_state.json.
If the account is not logged in or Amazon blocks navigation, the check can complete with “may require login”.
Similar to orders, but checks the basket/cart and stores results in profiles/<profileId>/basket_state.json.
The UI entry exists, but message checking is not implemented in the current build yet (it shows “coming soon”).
Proxy IP Safety
When you run multiple profiles, the biggest operational risk is accidentally sending two profiles through the same exit IP. The app includes two related features to help you detect and reduce IP reuse.
From the Profiles page right-click menu, Check Proxy opens the profile headless, detects the effective exit IP, shows it in a popup, then closes the browser.
If that exit IP was last seen on a different profile, the popup includes a conflict warning.
If enabled in the Warming dialog or Schedule dialog, the app performs an exit-IP check before starting a warming run. It stores the last-seen mapping in profiles/ip_usage.json and blocks runs when the same IP was used recently by another profile (based on your TTL).
If you enable Auto-rotate, the app calls your Change IP URL (HTTP GET) when an IP conflict is detected, waits the configured settle delay, then re-checks the exit IP. It retries up to Max rotate attempts.
If the rotation URL fails, times out, or is empty, the warming run is stopped with an error.
Warming Settings
Warming settings are configured from the Profiles page via Start Warming or Configure Warming. The app saves these settings per profile so your next run starts from the same baseline.
Choose Turbo / Advanced / Balanced / Basic. Internally, a plan controls the “intensity” of behavior: how many actions happen per burst, scroll depth, delays between actions, and pauses between bursts. The UI labels show typical action rates, but the actual behavior is driven by these ranges.
- Actions per burst: how many actions happen before a pause.
- Action delay: delay between actions (ms).
- Burst pause: how long the engine pauses between bursts (ms).
- Scroll depth: how far down pages the session scrolls (0–1).
- Search vs browse ratio: higher means more searches relative to browsing.
- Extra interactions chance: probability of additional mouse movement / interaction.
| Plan | Actions/Burst | Action Delay | Burst Pause | Scroll | Search Ratio |
|---|---|---|---|---|---|
| Turbo | 10–15 | 500–1500ms | 1500–4000ms | 0.9 | 0.8 |
| Advanced | 8–12 | 800–2000ms | 2000–5000ms | 0.8 | 0.7 |
| Balanced | 5–8 | 1500–3000ms | 4000–8000ms | 0.6 | 0.5 |
| Basic | 3–5 | 2500–5000ms | 6000–12000ms | 0.4 | 0.3 |
Duration is per run (minutes). Region controls the Amazon locale. Category controls the kind of searches performed. If you select Custom Terms, you can supply comma-separated queries.
Optional pre-warm phase to establish cookies before the main session. Pick a cookies plan (Fast / Balanced / Thorough).
Once a profile completes Initial Cookies successfully, the engine remembers that and skips it on future runs for that profile.
Runs the session without a visible window. This option is available in both the Warming dialog and the Schedule dialog.
- Prevent duplicate exit IPs: checks the exit IP before warming and blocks recent reuse (based on TTL).
- Auto-rotate on conflict: calls your Change IP URL and retries (with max attempts + settle delay).
- Avoid reuse TTL: how many hours an exit IP is considered “recent”.
- Change IP URL: your rotation endpoint (HTTP GET). Required if auto-rotate is enabled.
- Max rotate attempts: how many rotation cycles to try before failing the run.
- Settle delay: how long to wait after rotation before re-checking the exit IP (milliseconds).
Quick Warm uses the profile’s saved warming config (plan, duration, region, category, headless) and starts immediately. In the current build it always runs with Initial Cookies disabled for speed.
- Warming Plan: controls intensity ranges (actions per burst, delays, pauses, scroll depth).
- Duration: how long the run should last (minutes).
- Region: selects the Amazon domain/locale used during the run.
- Search Category: picks a category preset; Custom Terms enables comma-separated queries.
- Enable Initial Cookies Phase: runs the pre-warm step; Cookies Plan selects fast/balanced/thorough.
- Run in Background (Headless): runs with no visible UI.
- Prevent duplicate proxy IPs: checks exit IP before warming using profiles/ip_usage.json.
- Auto-rotate on conflict: on conflict, calls Change IP URL, then re-checks IP up to max attempts.
- Avoid reuse TTL: how long an IP is considered “recent” for conflict checks (hours). If set to 0, any previous use can conflict.
- Max rotate attempts and Settle delay: controls retry count and wait time after rotation (ms).
Schedules
Schedules let you automatically run warming sessions at specific times. You can create schedules from the Profiles page (right-click) or manage them on the Schedules page.
- Set the schedule name, duration per session, and whether it runs every day or only selected weekdays.
- Choose times per day. If you pick more than 1, the app calculates run times between a start/end window.
- Randomize times generates less predictable run times inside the window. For multi-times-per-day, it enforces spacing and falls back to evenly spaced times if the window is too tight.
- Select warming settings (plan, region, category, custom terms, headless, initial cookies).
- Optional: enable “Add Address During Warming” and choose an address + timing. The engine attempts to add the address (once per profile).
- Run Now, Activate/Deactivate, Edit, Clone, Regenerate Times, Delete
- Multi-select supports Bulk Edit and bulk delete.
If you create schedules for multiple profiles at once, you can choose a plan mode: Same plan for all, Rotate through plans, or Weighted random.
- Schedule Name: required (the dialog won’t save if empty).
- Profile: single-profile schedules target one profile; bulk mode creates one schedule per selected profile.
- Times per day: number of runs per day (1–12). If greater than 1, you also choose a start/end window.
- Between (start/end): defines the active window used to generate run times.
- Duration per session: minutes for each scheduled run.
- Run Every Day / weekdays: either daily, or pick specific weekdays.
- Schedule Active: enables or disables the schedule without deleting it.
- Randomize Times: generates less predictable times inside the window. For multi-runs, it enforces gaps between sessions.
- Warming Settings: plan/region/category/custom terms + headless + initial cookies/cookies plan.
- Plan mode (bulk only): same plan for all, rotate plans, or weighted random across profiles.
- Proxy Management: saves proxy conflict settings into the profile config so scheduled runs use the same rules.
- Add Address During Warming: attempts to add the selected address on Amazon.Next Run tries on the next session; Random Day 1–2 schedules a one-time random attempt within 48 hours.
Addresses
The app has an address pool and profile-level address assignment, and can also add the address on Amazon during warming (once per profile).
- Manage the shared address pool via Settings → Manage Addresses.
- Apply an address to a specific profile via Profiles → right click → Assign Address.
- If enabled, the engine reads addressDetails from the profile config and attempts to add it on Amazon.
- Once successful, it records state in profiles/<profileId>/address_state.json so it won’t keep retrying every run.
- Adding an address requires the Amazon account to be logged in and the address to include at least full name, postal code, and address line 1.
Realistic Multi-Profile Setup
A stable “real-world” setup is mostly about consistent profile config + proxy hygiene + controlled concurrency. Here’s a practical workflow that matches what the app currently does.
- In Settings, pick your anti-detect browser provider and set its API key/token/port.
- Set Max concurrent warmings to 1–2 to start (scale up gradually if everything is stable).
- On the Profiles page, verify each profile’s proxy with Check Proxy (this confirms the exit IP and warns on conflicts).
- Select a group of profiles → Configure Warming to apply one consistent baseline (plan/region/category/duration/proxy settings).
- Select the same profiles → Create Schedule(s) to bulk-create schedules. Use a reasonable number of sessions per day and enable randomization.
- If you use mobile proxies, turn on Auto-rotate and set a valid Change IP URL to recover from IP conflicts automatically.
A common baseline for multiple profiles is 2–3 runs per day at ~15 minutes per run, with randomized run times and a stable plan (recommended: Turbo).
- Times per day: 2–3
- Between: something like 09:00 → 21:00
- Duration per session: 15 min
- Randomize Times: ON
- Plan: Turbo (recommended)
- Max concurrent warmings: start 1–2, then increase only if IP conflicts and stability look good
When creating schedules in bulk, the app staggers each profile’s start time by 2 minutes to reduce synchronized behavior. Plan mode can also rotate or randomize plans across profiles to avoid identical patterns.
Troubleshooting
The app needs its local engine ready before automation actions like proxy checks can run. Ensure you’re logged in/licensed and that the desktop app is fully initialized.
Double-check your selected provider in Settings, and confirm the required API key/token/port is set. For local APIs, confirm the provider client is running on the same machine.
If “Prevent duplicate exit IPs” is enabled, the app warns when an exit IP was recently used by another profile. Use rotation (Change IP URL) or adjust TTL based on your workflow.