Skip to main content
The config channel notifies you when any contract-level configuration changes on the exchange: a new contract is listed, an existing contract is frozen or delisted, or parameters such as fee rates, margin tiers, or risk limits are updated. The notification is intentionally lightweight — it tells you that something changed and which contract was affected, but does not include the new values. After receiving a notification, re-fetch the configs endpoint via REST to get the latest configuration.

​
Subscribing

The config channel requires no parameters beyond the channel type:

​
Push message format

The data array may contain multiple notification objects if several contracts change configuration in the same block.

​
Notification fields

​
number
The type of entity that changed. Currently always 3, representing a contract-level configuration change.
​
string
The contract ID that was affected.
​
number
The configuration version number after this change. You can compare this against a locally stored version to determine whether you need to re-fetch, and to detect any missed notifications.
​
number
The type of change:

​
Handling a config notification

1

Receive the ConfigChanged notification

Your WebSocket handler receives a ConfigChanged message identifying the affected entityId and operation.
2

Re-fetch configs via REST

Send a POST /info request with {"type": "configs"} to retrieve the full, updated configuration for all contracts (or filter by entityId if the endpoint supports it).
3

Update your local state

Replace the configuration for the affected contract in your local cache. If operation is CREATE, add the new contract. If operation is STATUS and the contract is now delisted, remove it from your active contract list.
The ConfigChanged notification does not include the updated configuration values. You must re-fetch configs via POST /info after receiving this event to get the new parameters. Treating the notification alone as a source of truth will result in stale configuration data.
Subscribe to config at application startup alongside your other channel subscriptions. This ensures you are notified of new listings immediately — useful if your application auto-populates a tradeable asset list.
Contract configuration changes are rare compared to price and order events. Sending the full configuration payload on every change — which can be large when margin tier tables are involved — would waste bandwidth for most subscribers. The lightweight notification pattern lets you re-fetch only when necessary, keeping the WebSocket stream efficient.