OpenBB-finance/OpenBB · error · OpenBBError

The request is too large. Break up the request into smaller

Error message

The request is too large. Break up the request into smaller chunks.

What it means

Thrown by the Deribit provider's get_ohlc_data when the requested date range and interval expand to more than 15 HTTP requests. Each request covers at most 5000 candles (window_size=5000 in generate_urls), so the provider refuses ranges that would need >15 chunks instead of hammering the public get_tradingview_chart_data endpoint. It is a client-side guard, not an API response.

Source

Thrown at openbb_platform/providers/deribit/openbb_deribit/utils/helpers.py:317

            results.extend(
                df[
                    [
                        "date",
                        "symbol",
                        "open",
                        "high",
                        "low",
                        "close",
                        "volume",
                        "volume_notional",
                    ]
                ].to_dict(orient="records")
            )

    urls = generate_urls(symbol, start_date, end_date, new_interval)

    if len(urls) > 15:
        raise OpenBBError(
            "The request is too large. Break up the request into smaller chunks."
        )

    tasks = [get_one(url) for url in urls]

    await asyncio.gather(*tasks, return_exceptions=True)

    if results:
        return sorted(results, key=lambda x: x["date"])
    raise EmptyDataError("No data found for the given symbol and dates.")


async def check_ohlc_symbol(symbol: str) -> bool | str:
    """
    Check if the symbol has OHLC data.

    Parameters
    ----------

View on GitHub (pinned to 3e071fcc2c)

Solutions

  1. Split the date range into multiple calls, each small enough that (candles / 5000) <= 15 — e.g. for 1min data, request at most ~52 days per call and loop.
  2. Use a coarser interval (1d, 4h, 1h) which fits more history under the 15-URL cap.
  3. Tighten start_date/end_date to only the window you actually need instead of full instrument history.
  4. If you need bulk history, persist each chunk to disk (parquet/csv) so re-runs only fetch new windows.

Example fix

// before
obb.crypto.historical(symbol="BTC-PERPETUAL", interval="1min", start_date="2019-01-01", end_date="2024-01-01")  // raises

// after
import openbb as obb
for chunk_start, chunk_end in month_ranges("2019-01-01", "2024-01-01"):  # 1min: keep chunks <= ~50 days
    df = obb.crypto.historical(symbol="BTC-PERPETUAL", interval="1min", start_date=chunk_start, end_date=chunk_end).to_df()
Defensive patterns

Strategy: validation

Validate before calling

# Deribit: 5000 candles per request, 15 requests max -> 75_000 candles max
def max_days(interval: str) -> int:
    per_day = {"1min": 1440, "3min": 480, "5min": 288, "15min": 96, "30min": 48, "1h": 24, "4h": 6, "1d": 1}
    return 75_000 // per_day.get(interval, 1)

def assert_range_ok(start, end, interval):
    days = (end - start).days
    limit = max_days(interval)
    assert days <= limit, f"{days} days of {interval} exceeds limit {limit}; chunk into <= {limit}-day calls"

Try / catch

from openbb_core.provider.utils.errors import OpenBBError
try:
    df = fetch_window(symbol, start, end, interval)
except OpenBBError as e:
    if "too large" in str(e):
        raise ValueError("split range") from e
    raise

Prevention

When it happens

Trigger: Calling crypto/historical (Deribit OHLC) with a fine interval over a long span, e.g. 1min candles for 2+ years (1min * 5000 = ~3.5 days per URL, so >~52 days of 1min data exceeds 15 URLs). Also triggered by intervals like 1h over decades or requesting dates far before the instrument's creation when creation_date is used as the start.

Common situations: Scripts that default to 'max history' with 1-minute resolution; backtesting jobs that fetch full history in one call; re-running a query that used to work after changing interval from 1d to a smaller resolution.

Related errors


AI-assisted analysis of OpenBB-finance/OpenBB@3e071fcc2c (2026-08-14). Data as JSON: /api/errors/55016a339c61b72d. Report an issue: GitHub.