You have three client campaigns running, posts waiting to go live, and a community manager trying to reply to customers. Then X displays a rate-limit error.
Should your team wait 15 minutes? Try again tomorrow? Check a connected application?
A rate limit exceeded Twitter error means an account or application has reached an applicable usage limit. The fix depends on what stopped working. Posting, following, Direct Messages, API requests, and account access do not all follow the same rules.
Here’s how to identify the restriction, check when it resets, and get back to work without repeatedly triggering the same error.
Key takeaways
- Rate limit exceeded on Twitter/X means an account or application has reached an applicable activity or request limit. A locked account or login failure may involve a separate restriction.
- Not all X rate limits reset after 15 minutes. API limits commonly use 15-minute or 24-hour windows, while account-action limits and security restrictions have their own timing.
- X documents 500 Direct Messages and 400 follows per day, along with separate posting and reply limits.
- HTTP 429 identifies an exhausted API request quota. Developers can check the x-rate-limit-reset response header to determine when the applicable window resets.
- Switching devices does not reset an account-action limit. X counts activity across web, mobile, and other connected access methods.
- Multi-account teams need separate account ownership and shared activity records. Managing several legitimate client accounts does not remove X’s rules or increase the quota assigned to an account.
What does rate limit exceeded mean on Twitter (X)?
Rate limit exceeded on Twitter means X has temporarily restricted an account or application from making further actions or requests under an applicable usage limit.
X uses rate limits to manage demand on its systems and maintain service reliability. Its official limits documentation covers actions such as posting, following, sending Direct Messages, and changing account information.
The X API has its own request limits.
That difference matters. An exhausted posting quota, an API HTTP 429 response, and a locked account are not interchangeable problems.
Quick definitions
Account-action rate limit: A technical limit on how many times an account can perform an action, such as posting or following, within an applicable period.
API rate limit: A quota controlling requests to a specific X API endpoint, based on its configured limit and authentication context.
Account restriction: A limitation on account access or features, potentially requiring verification or another recovery step.
Login lockout: A temporary security restriction caused by repeated failed attempts to sign in.
Twitter rate limit vs. API limit vs. account restriction
Type | What it affects | How to recognize it | What to do first |
Account-action rate limit | Posts, replies, follows, DMs | Error while performing a specific action | Check the applicable account limit |
API rate limit | Applications using the X API | HTTP 429 response | Check the API response headers |
Account restriction | Account access or selected features | Locked-account or verification notice | Follow the account notice |
Login lockout | Signing in | Login temporarily unavailable after failed attempts | Stop attempts and wait for the security lock to clear |
A temporary rate limit does not automatically mean an account is suspended.
Before trying a fix, identify which of these situations matches your error.
Why does Twitter keep saying rate limit exceeded?
Twitter may keep showing a rate-limit error because the applicable usage window has not reset or an authorized application is continuing to make requests against an exhausted quota.
Similar-looking problems can also result from account restrictions.
Here are the main causes worth checking.
1. You reached a posting or reply limit
X can temporarily stop additional posts or replies when an account reaches its applicable publishing limit.
X currently documents 50 original posts and 200 replies per day for unverified accounts.
Its limits page also references a broader 2,400-updates-per-day limit, broken into smaller half-hourly intervals.
These numbers appear in different parts of the official documentation. X does not fully explain how they interact for every account category.
For an unverified account, do not assume the broader figure overrides the specifically published original-post and reply limits.
A publishing restriction may also involve a shorter interval rather than the full daily allowance.
2. You reached the following limit
X can restrict additional follows when an account reaches its technical limit or triggers a separate following restriction.
The documented technical allowance is 400 follows per day.
X also applies rules against aggressive following activity. Once an account follows 5,000 other accounts, further follows depend on account-specific ratios.
That means an account might encounter a following restriction for reasons beyond reaching the published daily number.
3. You reached the Direct Message limit
X limits accounts to 500 sent Direct Messages per day under its published technical allowance.
Activity from different devices does not create additional account allowances.
If one team member sends messages from a desktop while another uses a mobile app, those actions still belong to the same account.
Technical quotas are not permission to send unsolicited messages. X’s automation rules separately prohibit spam and unsolicited automated messaging.
4. A connected application exhausted an API quota
Authorized applications can encounter X API rate limits when they make more requests than an endpoint permits within its configured window.
Consider a reporting integration that checks recent posts throughout a campaign.
Every request uses capacity under the applicable API limit. If that limit is exhausted, the integration may receive HTTP 429 responses.
X distinguishes per-user and per-app limits. Whether requests affect the same quota depends on the endpoint and authentication context.
For teams using several integrations, the first question should be which application, endpoint, and credentials were involved.
5. Your account is locked or temporarily restricted
An X account may lose access to certain features because of a security concern or potential rule violation rather than an exhausted action quota.
X may ask the account owner to verify access through email, phone, or a CAPTCHA challenge.
Some limited accounts can continue using selected features while other functions remain unavailable.
These restrictions have their own recovery instructions.
If X displays a notice about account access or verification, follow its locked and limited accounts guidance.
6. Repeated login attempts caused a security lock
Multiple failed sign-in attempts can trigger an X security lock that temporarily prevents further login attempts.
X says this lock usually lasts about one hour.
Even the correct password may not work until the lock clears.
This is not the same as reaching a posting or API limit. Repeatedly attempting to sign in will not shorten the lockout.
What are the current Twitter/X rate limits?
X publishes technical limits for account actions and separate quotas for API endpoints.
The table below summarizes the account-action thresholds currently listed in the official X limits documentation.
Action | Published limit | Important detail |
Original posts, unverified accounts | 50 per day | Specific allowance published for unverified accounts |
Replies, unverified accounts | 200 per day | Separate published reply allowance |
Overall account updates | 2,400 per day | Also divided into half-hourly intervals, with applicability requiring attention to other published limits |
Direct Messages | 500 sent per day | Account-action limit |
Following | 400 per day | Additional following behavior rules apply |
Following beyond 5,000 accounts | Account-specific ratios | Depends on the account |
Changes to account email | 4 per hour | Time-based account limit |
API requests | Varies by endpoint | Depends on authentication context and the endpoint’s quota |
Source: X Help Center, About X limits. Last verified October 21, 2026.
X may temporarily reduce technical limits during periods of heavy platform usage.
Another important detail: account actions count across devices.
Moving from a browser to the mobile app does not reset the account’s daily posting or following allowance.
For developers, account-action thresholds should not be confused with endpoint quotas. An API endpoint’s documented request allowance is not permission to exceed X’s account-action rules.
How long does a Twitter rate limit last?
A Twitter rate limit lasts until its applicable usage window resets, but different actions and API endpoints have different reset periods.
Some API endpoints use 15-minute windows. Others use 24-hour periods, and certain endpoints also have shorter request-frequency restrictions.
Account-action limits can involve daily or shorter intervals.
Security locks and account restrictions follow separate recovery processes.
Twitter/X rate-limit duration and reset times
Problem | Documented timing | What to check |
Posting or replying | Applicable daily or half-hourly limits | Recent account activity and X’s error message |
Direct Messages | Daily allowance | Whether the daily limit has been reached |
Following | Daily technical limit or separate restriction | Follow activity and any account notice |
API HTTP 429 | Endpoint-specific window, commonly 15 minutes or 24 hours | x-rate-limit-reset response header |
Failed-login security lock | Approximately one hour | Login recovery instructions |
Locked or limited account | Depends on the restriction | Verification requirements or displayed recovery period |
Sources: X account limits, X API rate limits, and temporary login lockouts.
For posting limits, X recommends trying again after the relevant period has elapsed, mentioning a few hours for account update limits.
That is not a guarantee that every publishing restriction clears after a few hours.
When do Twitter rate limits reset?
Twitter rate limits reset according to the applicable action or API endpoint, not at one universal time for every account.
For the X API, use the reset timestamp returned in the response headers.
For ordinary account actions, check the error message and the appropriate published limit.
For locked or restricted accounts, follow the account notice.
A generic recommendation to wait 15 minutes can be useful for some API situations, but it should not replace diagnosis.
How to fix rate limit exceeded Twitter errors
To fix a rate limit exceeded Twitter error, identify the blocked action, stop repeating it, check the relevant limit, and follow the reset or recovery instructions for that specific problem.
Start with the error itself.
A complicated troubleshooting routine is unnecessary if the account has simply reached a documented daily allowance.
Step 1. Identify what stopped working
Determine which action failed:
- Publishing a post or reply
- Following an account
- Sending a Direct Message
- Signing in
- Making a request through an authorized application
Record the time and exact error message.
If you’re working with a team, note which account was affected and who was using it. Ask whether a connected application was active at the same time.
That information can narrow the investigation quickly.
Step 2. Stop repeating the failed action
Pause the activity until you know which restriction applies.
An exhausted technical quota does not reset because you repeatedly try the same action.
For API calls, repeating requests without checking the reset time can produce more HTTP 429 responses.
For login lockouts, X recommends waiting rather than continuing unsuccessful sign-in attempts.
Step 3. Check the relevant X limit
Compare the blocked activity with the official limit for that action.
A failed follow attempt belongs under following limits.
A failed API request belongs under the endpoint’s published request quota.
A notice asking for account verification belongs under account recovery.
You can find the account-action thresholds in X’s limits documentation.
If the issue involves an API integration, check its endpoint and authentication context instead.
Step 4. Review connected applications
Check whether authorized applications are continuing to perform account actions or API requests.
This is particularly important when several team members use different tools for scheduling, reporting, or customer communication.
Find out which application performed the failed request and whether other tasks are using the same applicable quota.
Pause unnecessary requests during the investigation.
For a persistent login lockout, X’s recovery instructions recommend temporarily disabling third-party applications, waiting, and confirming that normal sign-in works before reconnecting them.
Step 5. Complete verification if X requests it
If the account is locked or limited, complete the recovery steps displayed by X.
Depending on the situation, the platform may ask for email, phone, or CAPTCHA verification.
Some restricted accounts may have to remain in a limited state for a specified period.
If the notice provides a recovery process, follow it rather than assuming that switching devices will fix the restriction.
X explains the available options in its locked and limited accounts documentation.
Step 6. Retry after the applicable period
Try the affected action again only after the relevant quota resets or the account restriction clears.
For API requests, check the reset timestamp.
For normal account actions, use the applicable limit period and account notice.
If the problem remains, confirm whether the original error has changed.
A continued restriction may require an account-specific recovery step rather than more waiting.
Twitter rate limit exceeded: Diagnosis and recovery matrix
Use the matrix below to identify the affected action, the documented limit, and the appropriate recovery path before retrying.
| Error or symptom | Likely cause | Official limit or condition | First diagnostic step | Recommended recovery |
| Cannot publish a post | Posting quota | Published posting limits, including specific unverified-account allowances | Review recent publishing and the error message | Wait until the relevant limit resets |
| Cannot reply | Reply quota or account restriction | 200 replies/day documented for unverified accounts | Check reply activity and account notices | Pause replies and follow the relevant recovery instructions |
| Cannot follow another account | Following limit | 400 follows/day plus additional restrictions | Review recent following and account status | Stop following and follow X’s instructions |
| Cannot send more DMs | DM allowance or account restriction | 500 sent DMs/day | Review messaging activity and notices | Wait or complete account recovery |
| API returns HTTP 429 | Exhausted API request quota | Endpoint-specific per-user or per-app limit | Inspect response headers | Pause requests and retry after the reset |
| Cannot sign in after failed attempts | Security lockout | Temporary login protection | Check the sequence of failed sign-ins | Stop attempts and follow login recovery guidance |
| X asks for account verification | Locked or limited account | Account-specific recovery process | Read the verification prompt | Complete the required recovery process |
Sources: X account limits, X API rate limits, locked and limited accounts, and temporary login lockouts.
Some recovery periods are listed as variable because X does not publish one fixed duration for every account restriction.
For multi-account operations, add two fields to your team’s incident record: the responsible account owner and the time the next action is permitted.
That turns the matrix from a reference table into a usable troubleshooting process.
How to fix X API rate-limit errors (HTTP 429)
An X API HTTP 429 response indicates that a request has exceeded an applicable API rate limit and further requests against that quota must wait for the window to reset.
The correct limit depends on the endpoint and authentication method.
X API v2 distinguishes per-user limits, associated with user authentication, from per-app limits, associated with application-only authentication.
Its rate-limit documentation publishes endpoint-specific allowances.
What do the X API rate-limit headers mean?
The three rate-limit response headers show the maximum request allowance, remaining requests, and the window’s reset time.
Header | Meaning | How developers use it |
x-rate-limit-limit | Maximum requests allowed in the applicable window | Identify quota capacity |
x-rate-limit-remaining | Requests remaining | Monitor available capacity |
x-rate-limit-reset | Unix timestamp when the window resets | Calculate the next permitted retry time |
An illustrative response might contain:
x-rate-limit-limit: 300
x-rate-limit-remaining: 0
x-rate-limit-reset: 1790000000
Illustrative headers, not a live API response or a universal endpoint allowance.
When the remaining allowance reaches zero, the application should stop making requests against the exhausted quota until the applicable reset.
Are per-user API limits different from per-app limits?
Yes. Per-user limits and per-app limits apply to different authentication contexts and can have different request allowances for the same endpoint.
For instance, the X API currently documents these limits for recent post search:
Endpoint | Per-app limit | Per-user limit |
GET /2/tweets/search/recent | 450 requests per 15 minutes | 300 requests per 15 minutes |
Source: X API rate limits, verified October 21, 2026.
These figures are not interchangeable.
A developer should identify the authentication method and endpoint before calculating available capacity.
Multiple applications do not automatically share one universal API request allowance. The relevant quota depends on the authorization context.
How should an application handle HTTP 429?
An application should check the reset timestamp, stop requests against the exhausted quota, and retry only after the appropriate wait.
X recommends waiting until the rate-limit window resets and using backoff where necessary.
Here is a simplified Python example:
import time
import requests
def get_x_data(url, auth_headers, max_attempts=3):
for attempt in range(max_attempts):
response = requests.get(
url,
headers=auth_headers,
timeout=20
)
if response.status_code != 429:
response.raise_for_status()
return response.json()
reset_header = response.headers.get(
“x-rate-limit-reset”
)
if reset_header is None:
raise RuntimeError(
“Reset header unavailable. “
“Check the endpoint limit before retrying.”
)
try:
reset_time = int(reset_header)
except ValueError:
raise RuntimeError(
“Invalid API reset timestamp.”
)
if attempt == max_attempts – 1:
break
wait_seconds = max(
1,
reset_time – time.time() + 1
)
time.sleep(wait_seconds)
raise RuntimeError(
“Rate limit still exceeded after retries.”
)
Illustrative code for an authorized GET request. Supply the correct authentication headers for the endpoint. Production systems need additional error handling, request coordination, and monitoring.
The example makes a limited number of attempts and follows the reset timestamp instead of retrying continuously.
If the reset header is missing or invalid, it stops rather than guessing a short delay.
This does not increase the request allowance.
It helps an authorized application behave according to the applicable API restriction.
How can developers reduce unnecessary API requests?
Developers can reduce unnecessary API usage by monitoring request budgets, caching suitable responses, and avoiding repeated calls for unchanged information.
X’s API documentation also describes supported streaming options for use cases where repeated polling would otherwise create unnecessary requests.
A team that performs regular reporting should track:
- Endpoint and authentication context
- Documented request allowance
- Remaining requests
- Reset timestamp
- Application responsible for each request
- HTTP 429 incidents
The objective is to fit legitimate application work within the permitted quota, not find another account or integration to circumvent it.
How to manage X rate limits across multiple accounts and teams
Agencies can manage X rate-limit issues more effectively by coordinating account ownership, planning approved activity, and tracking connected applications and errors.
Consider a team with several client brands.
One person schedules content, another handles community replies, and a developer maintains reporting integrations.
Each may be working on a different task, but nobody has a complete view of the account’s activity.
This is an operational problem as much as a technical one.
A shared workload plan helps teams identify duplicate tasks, understand API usage, and respond consistently when X restricts an action.
Five best practices for multi-account X teams
- Assign a responsible owner to every account. Make one person accountable for account status, activity planning, connected applications, and escalation. Other team members can collaborate without leaving responsibility unclear.
- Coordinate publishing and communication plans. Maintain a shared schedule of legitimate posts, customer replies, and campaign tasks. Keep each brand’s content distinct and follow X’s restrictions on duplicative activity.
- Review authorized applications regularly. Check which integrations can access an account, what actions they perform, and whether they generate unnecessary API requests. Remove or pause applications that are no longer needed.
- Monitor API capacity before running automated jobs. Use endpoint-specific quotas and response headers to plan reporting and other permitted integrations. Leave room for other expected requests using the same applicable limit.
- Record every meaningful restriction and recovery action. Keep the affected account, error, time, relevant quota, responsible owner, and resolution together. Use those records to improve workload coordination.
X’s automation rules prohibit attempts to circumvent API limits, non-API website scripting, and certain duplicative or spam-related activity.
Scheduling content does not make otherwise prohibited activity permissible.
Example 1: Plan an API reporting workload
A developer can calculate an estimated request budget before launching a reporting job against a documented endpoint limit.
Suppose a team needs 120 requests to the X recent-search endpoint during a 15-minute reporting window.
The API documentation lists a per-user allowance of 300 requests per 15 minutes for:
GET /2/tweets/search/recent
Assume the application is using appropriate user authentication and that no requests have yet been made against that applicable quota in the window.
Item | Example |
Documented endpoint limit | 300 per-user requests per 15 minutes |
Planned requests | 120 |
Average planned rate | 8 requests per minute |
Allowance not allocated to this job | 180 requests |
Planning window | 15 minutes |
Hypothetical planning example, not a recommended polling frequency or guaranteed available allowance.
The calculation is straightforward.
However, actual remaining capacity still depends on requests already made against the relevant quota. The team must monitor live response headers and comply with any other applicable restrictions.
If the endpoint becomes rate limited, the reporting job should pause until the appropriate reset.
Example 2: Coordinate three client X accounts
An agency handling three distinct client accounts can organize legitimate activity through separate ownership and editorial schedules.
Imagine the following plan:
Client | Planned original posts | Planned replies | Account owner |
Brand A | 2 | 3 | Community manager |
Brand B | 1 | 4 | Account manager |
Brand C | 2 | 2 | Social media specialist |
Hypothetical workload, not a recommended daily posting volume.
Each account has its own purpose, audience, and content plan.
Before starting work, the owner checks the account’s status and planned activity.
If Brand B encounters a posting restriction, its manager records the error, stops the affected action, and follows X’s recovery instructions.
The team should not transfer the blocked campaign activity to another account as a way to evade the restriction.
Other clients can continue their own legitimate, permitted work according to their separate business needs.
This approach does not increase technical limits. It makes the team’s responsibilities and recovery decisions easier to manage.
Organizing X creator, brand and client account workflows
Managing several X client and brand profiles is easier when each has a consistent working environment, a responsible owner, and a clear handoff process.
A social media manager might need to check one client’s X mobile app, review another brand’s web activity, and prepare a third account for a team handoff.
The difficulty is keeping the work organized without repeatedly mixing up sessions, instructions, and account responsibilities.
Multilogin is a cloud phone platform for multi-account management that supports both mobile and web workflows.
Its environments serve different purposes:
- Android cloud phones: Dedicated real Android devices hosted in the cloud for native mobile app workflows. Each mobile social profile can maintain its own app data and login history.
- Browser profiles: Isolated browser environments for web-based accounts, with separate cookies, sessions, and IP configurations.
- Central dashboard: A place to organize account profiles and manage team access and permissions.
- Organizational tools: Custom columns, color tags, and notes to identify clients, campaigns, owners, and workflow requirements.
For an agency, the benefit is practical.
A client account can have a recognizable working environment. The next team member knows which profile to open and can use the relevant notes during a handoff.
For X-specific setup, see cloud phone for Twitter/X and the guide to managing multiple Twitter accounts.
The Academy guide to creating multiple X accounts with cloud phones provides additional product setup context. Account creation and use must still follow X’s policies.
The platform offers a Free plan with no time limit and no credit card required. Paid plans start from $7.08 per month when billed annually, with Android cloud phones, browser profiles, proxy traffic, and mobile minutes included according to the selected plan.
These tools support account organization. They do not increase X posting limits, expand API quotas, or remove account restrictions.
For creator teams managing multiple brand or client profiles, Multilogin can help keep daily account work organized without turning your analytics workflow into a login mess.
Multilogin is not a way around platform rules; the safest approach combines clean account separation with original content, real engagement, and platform-compliant activity.
Download the X Rate-Limit Troubleshooting Matrix
The X Rate-Limit Troubleshooting Matrix is a proposed Academy resource designed to help teams diagnose restrictions, plan permitted workloads, and document recovery actions across client accounts.
Instead of investigating the same issue from scratch, teams can use one shared process.
The downloadable worksheet is planned around three areas.
Worksheet | What it records | Operational purpose |
Diagnosis | Account, error, affected action, official limit, reset or recovery requirement | Identify the correct restriction |
Workload planning | Client, owner, scheduled tasks, relevant API endpoints, estimated requests | Coordinate permitted activity |
Incident log | Error time, connected application, investigation, next step, resolution | Support team handoffs and follow-up |
The diagnosis worksheet can accompany the troubleshooting matrix above.
The workload-planning worksheet helps account owners see scheduled work and application request needs without confusing one account’s responsibilities with another’s.
The incident log provides the record needed when a problem reappears or changes.
X Rate-Limit Troubleshooting Matrix
Downloadable Academy resource. Link to be added after publication.
Final thoughts
A Twitter rate-limit error is easier to resolve once you identify which restriction applies.
Start with the blocked action. Check X’s official documentation. Wait for the relevant reset, or complete account verification if required.
For teams managing multiple client accounts, the same principle applies at a larger scale. Clear account ownership, documented application usage, and a shared troubleshooting record make it easier to investigate problems and coordinate the next permitted action.
The goal is not to work around X’s limits. It is to understand them and keep legitimate account operations organized.
Manage multiple accounts with Android cloud phones
Build account trust, reach new locations, and grow faster from one dashboard
Frequently Asked Questions: How to Grow Instagram Reels Engagement
Rate limit exceeded means an X account or application has reached an applicable activity or API request limit.
The affected action determines the relevant quota and recovery process.
An exhausted API quota is different from a locked account that requires verification.
Twitter may continue displaying a rate-limit error because the relevant quota has not reset or authorized integrations are still making requests against an exhausted limit.
Check which action failed and whether X has displayed an account restriction.
For an API integration, review the endpoint, authentication method, and response headers.
Identify the blocked action, stop repeated attempts, check the official limit, and retry only after the applicable reset or recovery process.
For API errors, inspect x-rate-limit-reset.
For locked accounts, follow X’s verification instructions.
Changing devices does not reset a technical account-action limit.
A Twitter rate limit lasts for the applicable action or API window, which varies according to the restriction.
API endpoints commonly use 15-minute or 24-hour windows.
Posting limits can involve shorter intervals within a daily allowance. A temporary login lockout after repeated failed attempts generally lasts about an hour.
X rate limits reset when their applicable usage windows end, not at one universal reset time.
API responses can provide a Unix reset timestamp.
For ordinary account actions, check the documented limit and X’s error message. For account restrictions, follow the recovery notice.
Yes. X API limits control requests to individual developer endpoints, while account-action limits govern activities such as posting, following, and sending Direct Messages.
API quotas can differ by endpoint and authentication context.
An API application may receive HTTP 429 while the account remains usable through X’s regular interface.
X publishes specific posting and reply limits for unverified accounts, but verification does not provide a universal exemption from account or API restrictions.
The official limits page documents 50 original posts and 200 replies per day for unverified accounts.
It does not establish a single higher allowance applicable to every verified-account action.
Verification also does not remove X’s automation rules.
