Exchange rate limit

An exchange rate limit is the maximum number of API requests, or the maximum request weight, that an exchange accepts from one IP address or API key in a given time window; exceeding it returns errors and, if it continues, a temporary ban of the IP or key.

Why it matters

Automation makes many more requests than a human: setting leverage, placing the entry, creating protective orders, polling positions and checking fills for every signal on every account. Limits are shared across everything that uses the same IP or key, so one badly behaved loop can block orders for every other account on the same server. A ban during a fast market is the worst case: positions cannot be opened, and stops that live only in software cannot be moved. Limits also differ between exchanges and between endpoints, so a platform has to budget them rather than discover them by hitting them.

How AlgoVesta handles it

AlgoVesta keeps the number of calls per order fixed and small, and reads market data from shared public feeds rather than polling the exchange once per account. Request budgets are tracked per exchange and per key, and when a venue answers with a rate-limit or ban response the affected key or server backs off instead of retrying immediately; the condition is recorded and surfaced in the dashboard. Bans reported by a shared testnet are kept separate from live-market bans so a test environment cannot take live execution servers out of rotation. Stops and targets are placed as resting orders on the venue, so a temporary limit does not leave a position unprotected. Historical data and other heavy reads run from separate machines so they cannot consume the execution servers' budget. See retry logic and the Supported exchanges page.

Example

During a market spike a signal channel fires eight signals in a minute for one account. Each executes with its fixed set of calls, well inside the exchange's per-minute budget; positions are opened with their stops resting on the exchange. Had the exchange returned a rate-limit error mid-way, the remaining signals would have been recorded as blocked with that reason, and the key would have paused before the next attempt instead of triggering a longer ban.

Common mistakes

• Polling positions or prices in a tight loop per account, which burns the shared budget.
• Retrying immediately after a rate-limit error, which extends the ban.
• Assuming limits are per account when the exchange counts per IP.
• Running data collection and order execution from the same IP address.