Capabilities

​

What capabilities promise

• Nothing is left out. Every operation and every variant always appears. Unsupported entries say NotSupported explicitly, so a missing field never has to be interpreted.
• One shape everywhere. Every host publishes the same tree, and every venue publishes the same tree. Code that reads one host’s capabilities reads them all, including paper hosts.
• Decide before calling. If the capabilities say an operation is supported for a market and your inputs follow that market’s published rules, Plurex passes the request to the host. If they say it is not supported, the call returns 422 NotSupported. The host can still refuse a request for reasons no capability describes, such as insufficient funds.
• Every option has its own flag. Plurex never infers one capability from another. For example, supportsPositionEffect is independent of whether the market has a position mode setting.
• Plurex validates exactly what it publishes. Order rules are checked as published, and Plurex never rounds your inputs. See Market order rules.

​

Where capabilities live

​

The header: area, operation, variant, support

"orders": {
  "getOrder": {
    "byId": { "type": "Supported", "implementation": "Native" },
    "byClientOrderId": { "type": "NotSupported" },
    "byClientOrderIdForInstrument": { "type": "Supported", "implementation": "Native" }
  }
}

​

The market: descriptors with nullable presence

• A descriptor that is null means the market does not support that thing at all. For example, orderTypes.market: null means no market orders on this market, and settings.leverage: null means the market has no leverage setting.
• A non-null descriptor carries the terms you need: increments, minimums, time-in-force sets, candle intervals, the statistics window.
• Inside a descriptor, each operation has its own flag: get for a read, list and listBefore for candles, and setEffectScope (non-null when the setting can be changed). A non-null descriptor can still have one of its flags false, so check the specific flag.

​

Support values

"listOpenOrders": {
  "global": { "type": "Supported", "defaultOrdering": "ReverseChronological", "implementation": "Emulated" },
  "byInstrument": { "type": "Supported", "defaultOrdering": "ReverseChronological", "implementation": "Native" }
}

​

Native and emulated

• Native: the host’s own operation is used.
• Emulated: Plurex builds the result from other host calls, or performs the operation itself.

​

Always supported

​

Can I do X on market M of host H?

canDo(header, market, area, operation, variant, inputs):
    support = the header entry for this operation and variant      # always present; path depends on the area

    if support.type == "NotSupported":  return NO                 # the call returns 422 NotSupported
    if support.type not in ("Supported", "PerMarket"):
        return NO                                                  # a type you do not recognise

    if the operation takes no instrument:
        return support.type == "Supported"

    if market is null:  return NO                                  # the host or venue does not list it

    descriptor = the market's descriptor for this operation, if it has one
    if descriptor exists:
        if descriptor is null or its flag for this operation is false:  return NO
        if inputs break the descriptor's terms:  return NO          # the call returns 422 Rejected
        return YES

    return support.type == "Supported"                             # no market-level descriptor

from decimal import Decimal

def support_type(header, area, operation, variant=None):
    entry = header["capabilities"][area][operation]
    return (entry[variant] if variant else entry)["type"]

def can_set_leverage(host, market, leverage: Decimal):
    if market is None:
        return False                      # the host does not list this market
    if support_type(host, "marketSettings", "setMarketLeverage") != "PerMarket":
        return False                      # NotSupported, or a value you do not recognise
    spec = market["settings"]["leverage"]
    if spec is None or spec["setEffectScope"] is None:
        return False                      # 422 NotSupported on this market
    lo, hi, step = Decimal(spec["min"]), Decimal(spec["max"]), Decimal(spec["step"])
    if lo == hi:
        return leverage == lo             # a single fixed leverage
    return lo <= leverage <= hi and (leverage - lo) % step == 0   # off the grid is 422 Rejected

def can_get_order_by_client_id(host):
    return support_type(host, "orders", "getOrder", "byClientOrderId") == "Supported"

​

NotSupported and Rejected

​

Caching and refreshing

• Load headers and the market summaries you trade at startup.
• Refresh them periodically. How often depends on your tolerance for stale rules; for most systems, minutes to hours is enough.
• After a 422 NotSupported on a call your cache said was supported, reload the relevant header and market summary before deciding again.
• After a 422 Rejected on order inputs you built from cached rules, reload the market summary: an increment or minimum may have changed.
• Never hard-code rules from an example or from an earlier response.

​

Unknown values

• Ignore fields you do not recognise.
• Treat a type you do not recognise, in a support value or anywhere else, as unsupported for your purposes rather than as an error.
• Treat unknown enum values in sets such as supportedTimeInForce, supportedTransactionTypes or supportedIntervals as values you will not use.
• Send only values the market’s capability sets list. Requests are strict: an enum value the API does not define returns 400 InvalidRequest, and a defined value the market does not list returns 422.

​

Paper hosts

​

In depth