# 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) - For path/query parsing issues caused by bad URL construction, see [400: URL Anatomy (Path vs Query Parameters)](https://www.marketdata.app/docs/api/troubleshooting/url-parameters). 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: ```text https://api.marketdata.app//?key=value&key2=value2 ``` If you need a step-by-step URL-building guide, use: - [400: URL Anatomy (Path vs Query Parameters)](https://www.marketdata.app/docs/api/troubleshooting/url-parameters) ## 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: ```json { "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: - [400: Invalid Option Symbol](https://www.marketdata.app/docs/api/troubleshooting/invalid-option-symbol) ## Case 4: `date` Parameter Is Historical-Only You may receive: ```json { "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 ```http # 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 Bad Request

Bad Request

Request Line is too large (XXXX > 4094) ``` 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