Gap
The Limitless internal order client (core/src/exchanges/limitless/client.ts:322) implements cancelAllOrders(marketSlug: string) which cancels all of the authenticated user's open orders in a given market. This method is never exposed as a public method on LimitlessExchange, so neither the sidecar dispatch layer nor either SDK can route calls to it. The only access path is callApi("OrderController_cancelAllOrders", { slug }), an untyped escape hatch.
Core
Spec: core/specs/limitless/Limitless.yaml — DELETE /orders/all/{slug} with operationId OrderController_cancelAllOrders. Description: "Cancel all of a user's orders in a specific market."
Internal client: core/src/exchanges/limitless/client.ts line 322:
async cancelAllOrders(marketSlug: string) {
// calls this.orderClient.cancelAll(marketSlug)
return await this.orderClient.cancelAll(marketSlug);
}
Public exchange class: core/src/exchanges/limitless/index.ts — LimitlessExchange has cancelOrder(orderId) at line 350 but no cancelAllOrders(marketSlug) method. The internal LimitlessOrderClient.cancelAllOrders is called nowhere inside the exchange adapter.
TypeScript SDK
Missing — no cancelAllOrders in sdks/typescript/pmxt/client.ts. The Limitless exchange class in the SDK wraps only methods that LimitlessExchange exposes, so the gap propagates directly.
Python SDK
Missing — no cancel_all_orders in sdks/python/pmxt/client.py or sdks/python/pmxt/_exchanges.py.
Evidence
# Internal implementation exists
grep -n "cancelAllOrders" core/src/exchanges/limitless/client.ts
# line 322: async cancelAllOrders(marketSlug: string)
# Public exchange class does NOT expose it
grep -n "cancelAllOrders" core/src/exchanges/limitless/index.ts
# (no matches)
# Neither SDK wraps it
grep -rn "cancelAllOrders\|cancel_all_orders" sdks/
# (no matches, excluding API_REFERENCE docs)
The capability exists in the underlying HTTP client but was never wired into the exchange adapter's public interface, so it is unreachable through any standard SDK path.
Impact
Limitless users who need to flatten all open orders in a market (e.g., on market close, during a rebalance, or on error recovery) must iterate fetchOpenOrders() and call cancelOrder() for each order individually. This is N round-trips instead of one, introduces latency and partial-cancellation risk, and defeats the purpose of the batch endpoint the Limitless API already provides.
Found by automated Core-to-SDK surface coverage audit
Gap
The Limitless internal order client (
core/src/exchanges/limitless/client.ts:322) implementscancelAllOrders(marketSlug: string)which cancels all of the authenticated user's open orders in a given market. This method is never exposed as a public method onLimitlessExchange, so neither the sidecar dispatch layer nor either SDK can route calls to it. The only access path iscallApi("OrderController_cancelAllOrders", { slug }), an untyped escape hatch.Core
Spec:
core/specs/limitless/Limitless.yaml—DELETE /orders/all/{slug}with operationIdOrderController_cancelAllOrders. Description: "Cancel all of a user's orders in a specific market."Internal client:
core/src/exchanges/limitless/client.tsline 322:Public exchange class:
core/src/exchanges/limitless/index.ts—LimitlessExchangehascancelOrder(orderId)at line 350 but nocancelAllOrders(marketSlug)method. The internalLimitlessOrderClient.cancelAllOrdersis called nowhere inside the exchange adapter.TypeScript SDK
Missing — no
cancelAllOrdersinsdks/typescript/pmxt/client.ts. The Limitless exchange class in the SDK wraps only methods thatLimitlessExchangeexposes, so the gap propagates directly.Python SDK
Missing — no
cancel_all_ordersinsdks/python/pmxt/client.pyorsdks/python/pmxt/_exchanges.py.Evidence
The capability exists in the underlying HTTP client but was never wired into the exchange adapter's public interface, so it is unreachable through any standard SDK path.
Impact
Limitless users who need to flatten all open orders in a market (e.g., on market close, during a rebalance, or on error recovery) must iterate
fetchOpenOrders()and callcancelOrder()for each order individually. This is N round-trips instead of one, introduces latency and partial-cancellation risk, and defeats the purpose of the batch endpoint the Limitless API already provides.Found by automated Core-to-SDK surface coverage audit