Accounts
Manage Telegram accounts in TelegramOS: import sessions, isolate each account with its own proxy, monitor health, and respond to restrictions.
Every Telegram account in your workspace is either rented from the platform pool, or owned (uploaded by you).
New accounts ramp up over about 5 days. Every new account (imported, logged in by phone or QR, or rented from the pool) starts inwarmingand can send from minute one on a small hourly budget: 3 on day 0, 8 on day 1, 15 on days 2–3, 25 on days 4–5, thenactiveat 30. Rented accounts keep the warm-up progress they made in the pool, so an account that is alreadyactivethere arrivesactive.POST /api/accounts/{id}/skip-warmupends the warm-up early: owned accounts any time, rented accounts after 3 days. The stage-by-stage chart is under Automation › Warm-up schedule.
Rented vs owned
| Capability | Rented | Owned |
|---|---|---|
| Origin | Allocated from platform pool | You upload Telegram Desktop session ZIP |
| Login-code chat (peer 777000) | Hidden | Visible |
| Login codes / 2FA codes | Cannot be read | Visible |
| Proxy | Pinned to rental proxy, cannot change | You attach your own proxy |
| Phone number | Visible but cannot reach SIM | Visible, belongs to you |
| Deletion | Released at subscription end, or $1 permanent delete | Delete from Accounts page |
| Bulk delete | Forbidden | Allowed |
| Telegram bans | Not replaced. The rental stays yours until its term ends; release it for free or rent a new bundle | Not refundable |
Why login codes are hidden for rentals: The chat with peer ID 777000 is where Telegram delivers login codes. If a rental holder could read it, they could log in to the underlying phone number from another client. The platform hides that chat so the rental boundary holds.
Account isolation: three layers
| Layer | Enforcement | What it buys you |
|---|---|---|
| Per-account runtime isolation | Structural. By the runtime | Each account runs in its own OS process with own session file, fingerprint, connection, and auth-key. No connection multiplexing. |
| Per-account proxy isolation | Structural. By the runtime | Each account pinned to one dedicated proxy. No sharing. |
| Tenant-to-tenant on rented accounts | Data-lifecycle. Allocation rule + wipe | Only accounts currently unallocated in the pool are rented. At release, chats are wiped on both sides, the tenant binding is cleared and the account returns to the pool for a later tenant. |
Wiped between tenants: Pool accounts are recycled. Before an account can be rented again, the reclamation worker deletes every chat on both sides and clears the previous tenant, so you never see an earlier tenant's conversations. Accounts whose session died are quarantined and not rented again.
Account lifecycle states
| Status | Meaning | Outbound send budget |
|---|---|---|
| importing | Session being prepared | 0/hr |
| inactive | Parked or no proxy attached | 2/hr |
| warming | Days 0–5, four stages | 3 → 25/hr by stage |
| active | Full automation eligible | 30/hr + global 10/sec ceiling |
| paused | Paused by you, or by the platform (e.g. IP leak, data cap) | 0/hr |
| banned | Terminal. Not replaced; release the rental or delete the account | - |
| error | The worker could not run the account. Recoverable | - |
POST /api/accounts/{id}/reset-status moves an error or paused account back to active; only banned accounts are refused.
A flood-wait does not change the status. The account is held behind a short flood-wait gate, its queued tasks wait instead of being dropped, and a warming account drops back one stage. See Automation › Flood-wait detection.
The status budget is the ceiling for the account as a whole. Inside it, every action type has its own per-account budget — replies 60/hour and 300/day, campaign and cold sends 10/hour and 40/day, forwards 20/hour and 200/day — listed under Limits › Sending limits. The effective cap is the lower of the two.
Health score
| Band | Breaker | What it can do | Recovery |
|---|---|---|---|
| 80-100 | CLOSED | All automations | +5 per healthy tick |
| 50-79 | CLOSED | Refuses new bulk-send. DMs/replies unaffected | +5 per tick |
| 25-49 | CLOSED | Bulk send + group joins refused | +5 per tick |
| 1-24 | CLOSED/HALF_OPEN | Outbound paused. Connection stays open | Auto-clears on recovery |
| 0 | OPEN | Suspended | Not automatic: release or delete a rental, contact support for owned |
Score decreases: -20 for health-check failure, -30 for auth-key error, -15 per flood-wait in the last 7 days (capped at -45), pinned to 0 on confirmed Telegram ban.
Active-session enforcement
Every 6 hours, the platform checks each rented account for unknown Telegram sessions. Unknown sessions trigger a notification with two actions: It's me (approve) or Terminate (kill the session).
Connection rules
- Rental proxies pair only with rental accounts
- Your own proxies pair only with your owned accounts
- Crossing streams is refused
- One proxy = one account at a time
- Extra rental proxies can be purchased for additional rental accounts
FAQ
Can I read login codes for an owned account? Yes. Owned accounts have no redactions.
Can I read login codes for a rental account? No. Hidden to protect the rental boundary.
Can I delete a rental account? Via $1 permanent delete under Billing, or released at subscription end.
What happens at subscription expiry? 5-day grace window with full access. After grace, chats are wiped and the account returns to the pool.
My uploaded account got banned. Refund? No. You supplied the session. Banned rentals are not replaced either; release them and rent a new bundle.
Can I move an account from rented to owned? No. They are fundamentally different.