-
-
Notifications
You must be signed in to change notification settings - Fork 116
Description
Bug Report: Incorrect STRIKE_TYPE Field Documentation in LevelOneOptionFields
Description
There is a discrepancy between the Schwab API documentation and the implementation in the LevelOneOptionFields enum in schwab/streaming.py. Field index 20 is labeled as "STRIKE_TYPE" in the code but should be "STRIKE_PRICE" according to the official Schwab documentation.
Official Documentation vs. Current Implementation
According to the official Schwab API documentation:
| Field Index | Field Name | Type | Description |
|---|---|---|---|
| 20 | Strike Price | double | Contract strike price |
But in the current implementation:
#: Strike type
STRIKE_TYPE = 20Impact
This mismatch causes confusion when parsing option data. When trying to access the strike price using the field name rather than index, developers may use the wrong field name (STRIKE_TYPE instead of STRIKE_PRICE).
The issue becomes apparent when trying to access this field by name in code:
# This fails with: AttributeError: type object 'LevelOneOptionFields' has no attribute 'STRIKE_PRICE'
fields_enum.STRIKE_PRICESample Response Data
Here's a sample response from the API showing that field index 20 is indeed the strike price:
{
"key": "SPY 250421P00512000",
"delayed": false,
"assetMainType": "OPTION",
"cusip": "",
"1": "SPY 04/21/2025 512.00 P",
"2": 0.02,
"3": 0.03,
"4": 0.02,
"5": 3.85,
"6": 0.02,
"7": 0.605,
"8": 216581,
"9": 592,
"10": 14.67855532,
"11": -1.88,
"12": 2025,
"15": 0.49,
"16": 58,
"17": 123,
"18": 1,
"20": 512,
"21": "P",
"22": "SPY",
"23": 4,
"25": 0.02,
"26": 21,
"27": 0,
"28": -0.0527405,
"29": 0.09448764,
"30": -0.02536034,
"31": 0.00842988,
"32": -6.192e-05,
"34": 0.02536034,
"35": 513.88,
"37": 0.025
}As you can see, field "20" contains the value 512, which is the strike price.
Recommended Fix
Update the field name in LevelOneOptionFields enum:
# Change from:
#: Strike type
STRIKE_TYPE = 20
# To:
#: Strike price
STRIKE_PRICE = 20Maintaining backward compatibility could be achieved by keeping both field names if needed.