Skip to main content

400: Bad Request

Use this page for all 400 BAD REQUEST errors.

A 400 means the request could not be parsed or validated as valid input.

What Usually Causes 400​

  1. URL is constructed incorrectly (path vs query string mixups)
  2. Query parameters are malformed (? / & / key=value issues)
  3. Parameter type or format is invalid (string where number/date is expected)
  4. Parameter value is unsupported or out of range
  5. Option symbol is not valid OCC format
  6. date parameter is used in a current-data request (historical-only usage)
  7. URL is too long — most often caused by packing too many tickers into a single multi-symbol request

Case 1: URL Construction Problems (Path vs Query)​

Common examples:

  • Putting query parameters in the path segment
  • Missing ? before query parameters
  • Using wrong separators between parameters

Correct structure:

https://api.marketdata.app/<endpoint-path>/?key=value&key2=value2

If you need a step-by-step URL-building guide, use:

Case 2: Invalid Parameter Type/Format/Value​

You can get 400 when a parameter cannot be parsed correctly or violates endpoint rules.

Examples:

  • Sending text where a numeric value is expected
  • Sending a malformed date
  • Sending an unsupported enum/value for a parameter
  • Sending a value outside allowed bounds

Fast check:

  1. Confirm parameter names exactly match the endpoint docs.
  2. Confirm each parameter value type/format is valid.
  3. Remove optional parameters and re-add one at a time.

Case 3: Invalid Option Symbol (OCC)​

You may receive:

{
  "s": "error",
  "errmsg": "Invalid option symbol. Use valid OCC symbology for the option symbol."
}

Meaning: request shape is valid, but optionSymbol is malformed.

For detailed format rules, examples, and validation workflow, use:

Case 4: date Parameter Is Historical-Only​

You may receive:

{
  "s": "error",
  "errmsg": "Invalid date. The date parameter is used for historical queries only."
}

Meaning:

  • Request can be otherwise valid
  • date was used in a current-data context

How to fix:

  1. For current data: omit date
  2. For historical data: provide a past trading date
# Current request (correct): no date parameter
GET https://api.marketdata.app/v1/options/quotes/OPTION_SYMBOL/

# Historical request (correct): includes date
GET https://api.marketdata.app/v1/options/quotes/OPTION_SYMBOL/?date=2025-01-15

Case 5: URL Too Long (Multi-Symbol Requests)​

You may receive an HTML-formatted 400 BAD REQUEST response that does not follow the usual JSON error shape:

<html>
  <head><title>Bad Request</title></head>
  <body>
    <h1><p>Bad Request</p></h1>
    Request Line is too large (XXXX > 4094)
  </body>
</html>

This is returned by the web server before the request reaches the API, so it does not appear in your account's request log and does not consume credits.

The cause is exceeding the 4094-byte HTTP request-line limit. The most common trigger is packing too many tickers into a single multi-symbol call, for example:

  • /v1/stocks/prices/?symbols=...
  • /v1/stocks/bulkcandles/D/?symbols=...

How many symbols per request​

There is no application-level cap on symbol count — the ceiling is set entirely by URL length. As a rule of thumb:

  • An average 4-character ticker plus a separator comma takes 5 bytes.
  • Path, token, format, columns, and other query parameters typically consume 150–250 bytes of overhead.
  • That leaves roughly 3,800 bytes for the symbols list — about 700–800 typical-length tickers before requests begin to fail.

To stay clear of the limit, chunk multi-symbol requests into batches of 500 symbols or fewer. That leaves headroom for longer tickers (BRK.B, 5-letter Nasdaq tickers) and any additional query parameters you may add later.

How to fix​

  1. Reduce the number of symbols in the request.
  2. Split your symbol list into multiple smaller calls.
  3. If you must send a long list, drop any non-essential query parameters to free up URL space.

400 vs Other Status Codes​

  • 400: request input/format is invalid
  • 401: authentication issue (token missing/invalid)
  • 402: plan/entitlement limit reached
  • 403: forbidden by policy (for example multiple IP addresses)
  • 404: request format is valid, but requested resource was not found

If You Still Get 400​

  1. Log full request URL and all query parameters
  2. Compare request against endpoint docs field-by-field
  3. Re-test with only required parameters
  4. Add optional parameters back one at a time