Exchange
probable (core/src/exchanges/probable/)
Spec file
core/specs/probable/probable.yaml
Summary
The live GET /public/api/v1/events/ and GET /public/api/v1/events/{id} responses no longer include a status: string field on Event objects. The field has been replaced by five separate boolean flags:
| Field |
Type |
Description |
active |
boolean |
event is currently active |
closed |
boolean |
event is closed |
archived |
boolean |
event is archived |
live |
boolean |
event is live |
ended |
boolean |
event has ended |
The cached spec still documents status: string on the Event schema. api.ts reflects the stale schema.
Additionally, two field type changes on the Event response:
Event.volume — spec types as number; live API now returns as a string (e.g. "184032.00")
Event.liquidity — new field (not in spec at all), returns as a string
Runtime impact
The current normalizer (core/src/exchanges/probable/utils.ts:80, mapEventToUnified) does not read event.status from API responses — it uses query parameters (events_status) to filter by status rather than parsing the field from responses. Number() coercion in mapMarketToUnified (lines 49–50) handles the string volume/liquidity values without crashing.
Impact is spec/type accuracy, not a current runtime crash: the stale spec misleads future readers and makes the generated api.ts types wrong for any new consumer.
Action needed
- Update
probable.yaml Event schema: remove status: string, add the five boolean flag fields
- Add
liquidity: string to Event schema
- Change
volume type from number to string (or string | number if backward-compat needed)
- Regenerate
api.ts
Exchange
probable (
core/src/exchanges/probable/)Spec file
core/specs/probable/probable.yamlSummary
The live
GET /public/api/v1/events/andGET /public/api/v1/events/{id}responses no longer include astatus: stringfield onEventobjects. The field has been replaced by five separate boolean flags:activeclosedarchivedliveendedThe cached spec still documents
status: stringon theEventschema.api.tsreflects the stale schema.Additionally, two field type changes on the
Eventresponse:Event.volume— spec types asnumber; live API now returns as astring(e.g."184032.00")Event.liquidity— new field (not in spec at all), returns as astringRuntime impact
The current normalizer (
core/src/exchanges/probable/utils.ts:80,mapEventToUnified) does not readevent.statusfrom API responses — it uses query parameters (events_status) to filter by status rather than parsing the field from responses.Number()coercion inmapMarketToUnified(lines 49–50) handles the stringvolume/liquidityvalues without crashing.Impact is spec/type accuracy, not a current runtime crash: the stale spec misleads future readers and makes the generated
api.tstypes wrong for any new consumer.Action needed
probable.yamlEventschema: removestatus: string, add the five boolean flag fieldsliquidity: stringtoEventschemavolumetype fromnumbertostring(orstring | numberif backward-compat needed)api.ts