> ## Documentation Index
> Fetch the complete documentation index at: https://docs.upsidemax.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# WebSocket config: Contract Configuration Notifications

> Subscribe to the config channel to receive lightweight notifications when contract configuration changes — new listings, freezes, or parameter updates.

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:

```json theme={"system"}
{"method": "subscribe", "subscription": {"type": "config"}}
```

## Push message format

```json theme={"system"}
{
  "msg": "ConfigChanged",
  "channel": "config",
  "data": [
    {
      "entityType": 3,
      "entityId": "10000001",
      "version": 42,
      "operation": 3
    }
  ],
  "ts": 1782279307885
}
```

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

## Notification fields

<ResponseField name="entityType" type="number">
  The type of entity that changed. Currently always `3`, representing a contract-level configuration change.
</ResponseField>

<ResponseField name="entityId" type="string">
  The contract ID that was affected.
</ResponseField>

<ResponseField name="version" type="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.
</ResponseField>

<ResponseField name="operation" type="number">
  The type of change:

  | Value | Name     | Meaning                                                                                   |
  | ----- | -------- | ----------------------------------------------------------------------------------------- |
  | `1`   | `CREATE` | A new contract has been listed and is now available for trading                           |
  | `2`   | `STATUS` | A contract's trading status changed — it was frozen, unfrozen, or delisted                |
  | `3`   | `UPDATE` | One or more contract parameters were updated (fee rates, margin tiers, risk limits, etc.) |
</ResponseField>

## Handling a config notification

<Steps>
  <Step title="Receive the ConfigChanged notification">
    Your WebSocket handler receives a `ConfigChanged` message identifying the affected `entityId` and `operation`.
  </Step>

  <Step title="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).
  </Step>

  <Step title="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.
  </Step>
</Steps>

<Warning>
  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.
</Warning>

<Tip>
  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.
</Tip>

<Accordion title="Why is this channel notification-only?">
  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.
</Accordion>