AI Trading Bot API Limits: Why Another Key May Not Help

DN AI Trading Beginner Series · Reviewed 7 November 2026

Imagine a fictional setup in which one bot appears to work, then a second bot starts receiving rate-limit errors. Giving them different names and credentials may make the dashboard tidier. It does not answer whether their requests still leave through the same IP address, affect the same account or use a shared service.

The previous guide examined what an order instruction means. This guide asks a separate operational question: which budgets does a request touch before you can assess its capacity implications? It focuses on beginner spot-trading workflows and the surrounding automation services. It does not rank exchanges by speed or prescribe a retry loop.

Start with the counter, not the bot name

A request class is a specific operation you want to account for, such as one account-status query with defined parameters. A counter is the particular measure against which that operation is assessed. Its scope identifies the bucket: a key, an IP address, an account, an account-and-pair combination or another documented boundary.

The unit tells you what is counted. An HTTP request, a weighted request unit, an alert trigger and an open order are different quantities. The accounting rule tells you how that quantity changes: it might reset at a fixed boundary, decay over time, refill toward a ceiling or depend on order events.

Those distinctions make a claim such as “the API allows 100” incomplete. One hundred of what, for which identity, under which rule, and over which period? A useful record can answer those questions without exposing a secret key.

Use this table to identify questions, not to copy numerical quotas. The exact product, route and current documentation still govern your setup. A row for one service also does not account for every other service between the signal and the exchange.

Build a small map you can actually review

1. Name two concrete request classes. Enter how many of each belong to the batch you are examining. A strategy instruction such as “open a position” is too broad if the resulting requests are still unknown.
2. Name two counters separately. Keep each scope, unit, accounting window and observed usage attached to its own row. Two rows are a partial view, not a claim that your workflow has only two limits.
3. Decide whether each request counts in each row. Choose counted, explicitly not counted, or unknown. Supply a cost only when the relevant evidence establishes one.

The numerical comparison is deliberately narrow: one unchanged, reader-declared fixed window, with the snapshot and batch in the same bucket. Other counter types remain visible but unmodeled. Start with a fictional example if you want to see the distinction before recording your own assumptions.

Read the result literally. “Within entered budgets” describes the numbers on that counter’s card. It does not verify the provider’s current rules, identify every missing counter, reserve capacity or authorize an order. Use ordinary labels only; never paste API keys, secrets or signed request URLs into this worksheet.

1. Describe requests precisely enough to account for them

Start with a short inventory: what initiates work, what operation is requested and what parameters affect that operation. “Bot A checks the market” is not yet a request definition. A query for one market and a query for several markets may be different accounting cases.

There is a concrete example in the current 3Commas market-list endpoint. Its documentation gives different weights for requests covering one exchange and three exchanges. The changing input is part of the cost definition. That example does not establish the formula for another endpoint or a live account allowance. [9]

For your own record, distinguish a request you have observed from one you merely expect a connector to make. If a hosted service accepts one command but its downstream actions are hidden, do not invent a one-command-to-one-exchange-request relationship. Ask for the relevant implementation evidence or leave that mapping unknown.

Include routine account checks and reporting jobs in the inventory, alongside trading-related operations. The worksheet can represent only the two classes you enter; keep a separate list of omitted activity. This makes its limited coverage explicit instead of making a short form appear to cover a whole system.

Record: operation, product, parameter pattern, batch count, evidence source and any unobserved downstream work.

2. Identify who shares each bucket

Write a scope label that another reviewer can understand. “Key A,” “outbound network X” or “account A, pair B” is more useful than “my limit.” A descriptive label is enough for this exercise; the credential itself adds no accounting evidence.

Kraken’s support documentation illustrates why a single provider name is insufficient. Its public Spot Trades and OHLC limits use IP plus pair; other public endpoints use IP. Its private account-management and trading families use other boundaries. An authenticated bot can therefore interact with both credential-related and credential-independent restrictions. [4]

Build a list of possible co-users of each declared bucket: another bot, a reporting process, a manual script or a connector you operate. Mark the list incomplete if the hosting arrangement does not reveal all traffic. A usage snapshot can already contain work that the bot’s own logs do not explain.

The operational question is ownership. Who can explain the counter, coordinate its consumers and provide evidence when usage differs from the plan? Splitting bot names does not assign that responsibility automatically.

Record: bucket identity, known consumers, unknown consumers and the person or service responsible for the evidence.

3. Keep requests, weights and events in separate units

The same batch can contribute different amounts to different counters. Six requests costing two units each contribute twelve units to that counter. The request count is still six. Neither number can be transferred to another row without that row’s own rule.

In the map, “not counted” is an explicit assertion about one request-counter relationship. It is not a statement that the request is free of every restriction. “Unknown” means the relationship has not been established. Substituting zero for an unknown makes a missing fact look like spare capacity.

WebSocket terminology is another source of confusion. Binance Spot market-data streams distinguish client control traffic, including ping/pong and subscription messages, from the updates received by a bot. Connection attempts and stream counts have their own restrictions. These are different measures from the Spot request/response WebSocket API. [10]

Before comparing two values, read their unit labels aloud. “Twenty request-weight units” and “twenty open orders” are not two observations of the same quantity. Even identically named units can belong to different scopes or accounting rules.

Record: the unit for each counter and the evidence for counted, not counted or unknown on each request class.

4. Identify how the counter changes

A fixed-window sum is only one accounting model. Binance’s Spot WebSocket API describes multiple simultaneous intervals with boundary-aligned resets. Exhausting a longer interval can remain binding after a shorter interval resets. The same documentation says request weight is shared across connections from one IP. [11]

Coinbase Exchange documents a token bucket with refill and burst capacity. Those are time-dependent parameters. This article does not transplant that model or its numerical limits into Coinbase Advanced Trade. [6]

Binance’s Spot ORDERS counter has another important distinction: first fills can reduce it, while canceling or expiring an order does not reduce that counter. Treating it as a tally of currently open orders would misstate the rule. [3]

Kraken’s trading counter also involves decay and costs that can depend on order age. Its documentation says fixed increments can apply even when validation fails. A rejected request is therefore not universally a zero-cost event. [5]

The worksheet leaves these time- or state-dependent mechanisms unmodeled. That is useful information: it identifies where a simple addition problem stops being a defensible representation. Do not select “fixed window” merely because a documentation page mentions a minute or displays a reset timestamp.

Record: the accounting rule, the events that change the value and the evidence establishing that the chosen calculation applies.

5. Align the snapshot, scope and batch

A ceiling from one interval cannot be paired with usage from another. Nor can one key’s usage stand in for a shared account or network. For the worksheet’s fixed-window comparison, the entire entered batch must belong to the same accounting window as the usage snapshot.

Keep the source and time of each snapshot in your working notes. A fresh-looking number can still be the wrong measure. If the provider exposes several fields, identify which one belongs to this row before copying it.

The worksheet asks for your scope and window declarations separately. Checking them records what you assert; it does not independently verify either fact. If another process can consume the bucket after the snapshot, the arithmetic remains a conditional scenario. It has not acquired a reservation.

When evidence conflicts, preserve the conflict. At this review, Kraken’s formal REST guide and support page disagree on the cost of some history requests. We do not select a numerical default from that disagreement. The shared statements about scope and decay remain useful, while the disputed cost needs clarification. [2][4]

Record: snapshot source and time, exact counter, applicable window, concurrent-traffic assumption and unresolved documentation questions.

6. Explain exactly what another key would change

Make a before-and-after record. Does the proposed change affect a key-scoped counter, the outbound network, the trading account, the product or none of those? Which existing rows remain the same? Which genuinely require new evidence?

Do not infer a fresh usage value from a fresh label. In the worksheet, renaming “Key A” to “Key B” cannot change the arithmetic. A different snapshot is a separate input that needs its own basis. If the same shared-IP row still applies, its workload does not disappear because another credential is used.

Keep the purpose of a credential change explicit. Separating access responsibilities and establishing independent rate capacity are different questions. A change can serve an administrative purpose while leaving the binding limit untouched.

For a useful review, write one sentence per affected counter: “This row changes because this documented boundary changes; this other row remains shared.” If that explanation depends on an undocumented assumption, flag it before changing the running workflow.

Record: changed boundaries, unchanged boundaries, replacement evidence and any uncertainty about whether the new arrangement is supported.

7. Include the services before the exchange

An automation chain can have an alert source, a hosted bot platform and an exchange. Give each service its own identity in the map. A request addressed to the bot platform is not automatically a measured exchange request.

Current 3Commas API documentation lists weighted allowances for API keys and IPs, plus an IP raw-request burst rule. Its “tokens” are request-budget units in this context. The documentation does not establish every detail of the enforcement algorithm, so the worksheet must not silently assume a fixed-window model for it. [7]

TradingView separately describes alert-frequency restrictions for regular alerts and for watchlists, including whole-watchlist and individual-symbol limits. These concern signal generation. An exchange credential does not define those upstream boundaries, and an alert trigger is not the same unit as an exchange API request. [8]

Record: service, operation, observed response and any unverified translation from an upstream command to downstream requests.

8. Treat a reserve as a planning allowance

You may want to leave room for monitoring, reconciliation or cancellation-related work. Enter that allowance in the unit of each relevant counter. Keep it separate from the provider’s ceiling so a reviewer can see whether the batch fits the ceiling but consumes the room you intended to retain.

A number in this worksheet does not make the service prioritize that work. Nor does it prove that a cancellation will be accepted or that an earlier order has no fills. Kraken’s trading documentation has a narrow batch-cancel acceptance exception; that should not be generalized into a universal cancellation entitlement or universal blockage rule. [5]

A blank reserve remains unknown. An explicit zero means you entered no extra allowance for that row. Those are different records, even when the ceiling comparison itself is available. An allowance larger than the entire entered ceiling is an input configuration to correct.

If you already have a throttling response, preserve its route and error details. HTTP 429 identifies rate limiting, but the standard does not determine the server’s user identity or counting method; a Retry-After header is optional at that level. [12]

Follow the provider’s actual response contract. Binance Spot REST, for example, specifies Retry-After in seconds and warns that persistent violations can produce an IP ban. Its timeout guidance also distinguishes an unknown order outcome from a confirmed failure. [1]

The separate order-timeout guide handles the reconciliation question. A favorable budget calculation cannot establish whether a previous order executed.

Record: the purpose of the allowance, its unit, known response behavior and the unresolved order or service state.

One fictional batch, two different results

The map’s main example contains six status reads and two order-action requests. All names, limits, costs and usage values are synthetic. Neither request class instructs you to place a trade. For this arithmetic, assume each snapshot and the whole batch belong to its declared fixed window, with no other traffic or resets.

The first counter fits its entered ceiling and allowance. The second exceeds its entered ceiling by ten of its own units. We keep those observations separate. Adding the two projected usages would not create a meaningful universal API-budget number.

Now consider a conditional change: suppose independent evidence established a different key counter with usage zero, while all other entered assumptions stayed the same. That key row would project to ten. The shared-IP row would still project to 110. The calculation explains why improving one row may leave the relevant constraint unchanged; it does not claim that newly created real keys start at zero.

The reserve example changes the shared row’s usage to 70 and its allowance to 10. The same batch projects to 92, leaving eight. It fits the ceiling but leaves two fewer units than the reader intended to retain. That result is different from exceeding the ceiling.

The remaining examples show unknown costs, an unmodeled dynamic counter, a case within both entered budgets, and explicit zero or not-counted relationships. Editing an example keeps its fictional origin visible until you reset the record.

Methodology: separate arithmetic from evidence

DN Shared API Budget Map v1.0 is a deterministic worksheet for two request classes and two counters. The counter cards are independent. No provider quotas are preloaded, and no account is contacted to fill missing inputs.

For an eligible fixed-window card, the calculation is:

Arithmetic comparisons require the reader’s same-scope and same-window declarations. They assume the entire batch is in that window, with no intervening reset or unlisted traffic. The tool does not infer alignment from a label such as “minute,” from an IP-looking string or from the presence of a timestamp.

How unknown values behave

A counted relationship needs its request count and unit cost, including explicit zero where appropriate. A not-counted relationship contributes zero to that card, but a missing batch count still leaves the record’s documentation incomplete. Unknown relationships never become zero merely to produce a result.

The ceiling and allowance comparisons are separate. A missing allowance does not erase a known exceeded ceiling. When only part of a batch is known, the full projection stays unknown. Under the supported nonnegative-input assumptions, a clearly labeled known minimum can still demonstrate that the ceiling or intended allowance is already exceeded. It is never displayed as the complete batch.

Decay, refill, rolling windows, state-dependent changes and unspecified rules remain outside the numerical model. Select an unmodeled or unknown rule instead of forcing those mechanisms into a fixed-window sum. Equal remaining units preserve the entered allowance; exceeding a ceiling by any amount remains an exceedance.

What the record establishes

Inputs are decimal strings, and the calculation uses exact decimal arithmetic rather than rounding a near-boundary result into a different outcome. Request quantities are whole numbers. Blank values are unknown; unsupported or invalid input is identified. The tool has explicit precision limits and does not fall back to approximate calculations when its required arithmetic is unavailable.

The JSON and CSV exports capture the current inputs, reader declarations, results, source-review date and fictional-example origin. They contain your record rather than a hidden account measurement. CSV handles formula-leading labels as text. Keep the accompanying provider evidence and observation times with the export when handing the review to another person.

A complete two-counter record is still a two-counter record. It is not a certificate that every limit has been identified, that the platform will accept a request, or that an order is suitable. No throughput, retry time, fill, profit, cancellation success or provider safety score is calculated.

Use the map to make the next question specific

An incomplete map can produce a useful handoff. “Please investigate the API” is vague. “Which IP-scoped counter includes these two request classes, and what evidence identifies its current usage?” gives a developer or provider a precise question.

Keep unresolved items attached to the row they affect. If the cost changes with request content, identify the parameters. If the rule decays, request the appropriate model. If the provider does not expose a shared scope, record that limit on what your team can verify.

For adjacent decisions, use DN’s rate-limit documentation comparison, API performance and workload guide, Python bot API guide and REST, WebSocket and FIX comparison. Their questions are complementary. Here, the deliverable is a dated map of which request belongs to which counter.

Frequently asked questions

Primary sources

Official documentation reviewed on 7 November 2026 (SAST). Product, route, scope and accounting rule matter. These are documentation findings, not live quota measurements.

1. General REST API Information — Binance Spot
2. Spot REST Rate Limits — Kraken
3. Spot Unfilled Order Count Rules — Binance
4. What are the API rate limits? — Kraken
5. Spot Trading Limits — Kraken
6. REST Rate Limits Overview — Coinbase Exchange
7. Rate Limits — 3Commas REST API
8. Alert was triggered too often and stopped — TradingView
9. Get exchanges markets — 3Commas REST API
10. General WebSocket Streams information — Binance Spot
11. General WebSocket API Information — Binance Spot
12. RFC 6585, section 4 — 429 Too Many Requests