Account Channel

Topic: account:{user_id}

Everything the five per-type channels carry, on one join. The events and payloads are byte-identical to theirs; this is a subscription convenience, not a different feed.

["1","1","account:<user_id>","phx_join",{}]

What arrives

On join you receive four snapshots:

Event	Payload	Documented at
all_orders	{"orders": [...]}	Orders
all_trades	{"trades": [...]}	Fills
all_positions	{"positions": [...]}	Positions
balances	the balances object	Balances

There is no settlements snapshot, because settlements does not send one either.

After that, changes arrive under the same event names the per-type channels use, so nothing needs re-tagging if you migrate to this topic:

Event	Carries
new_open_order	one order
trade	one of your executions
updated_positions	changed positions
new_settlements	new settlements
update	the balances object
payment_update	a payment status change

account: does not accept an account_id; it serves the account the socket resolved at connect. To reach a second account you own, join balances separately for it.

Filtering by market

It takes the same optional market_ids filter as the per-type channels (see filtering), with one deliberate difference: balance frames are never filtered out. balances, update and payment_update describe the account, not a market, so a market_ids filter has nothing to match them against and lets them through.

["1","1","account:<user_id>","phx_join",{"market_ids":["<uuid>"]}]
["1","2","account:<user_id>","select_market_ids",{"market_ids":null}]

The filter distinguishes a snapshot from a delta. On join you receive all_orders even when the filter leaves it empty: [] tells you there is nothing in those markets, which is worth knowing. Afterwards, an update the filter empties is simply not sent, rather than arriving as an empty list.

Keeping it alive

["1","3","account:<user_id>","ping",{}]

The ping refreshes the session behind the channel. Without it the inactivity timer reaps that session and every fanned-in feed silently stops, so send it on a timer even though this topic arms no cancellation.

Use Cases

Use case	Message to send
Join and receive your whole account	["3","3","account:<user_id>","phx_join",{}]
Join filtered to two markets	["3","3","account:<user_id>","phx_join",{"market_ids":["<uuid>","<uuid>"]}]
Change the market filter without rejoining	["3","4","account:<user_id>","select_market_ids",{"market_ids":null}]
Keep the session alive	["3","5","account:<user_id>","ping",{}]

Do not also join a per-type channel

A socket joined to both account: and, say, orders: receives every order twice. Pick one.

No cancel-on-disconnect

account: does not support cancel_on_disconnect. Its ping keeps the session alive but arms no cancellation, so if you rely on resting orders being pulled when your socket drops, use orders and the per-type channels instead, for everything, not alongside account:. See Risk controls for the join payload and its ping contract.

Choosing between them

account: if you want everything on one join; the per-type channels if you want a subset without a filter, or if you need cancel_on_disconnect.