Streaming

Anthid provides real-time broker updates through gRPC streaming. While REST APIs are used for creating intents and querying historical data, the Streaming API delivers live order and position updates as they occur. Streaming allows applications to react immediately to broker activity without polling REST endpoints.

Availability

Streaming is available on all plans. Organizations may maintain multiple concurrent stream connections subject to plan limits. API-key connection limits are resolved from the organization’s billing limits.

Access

Streaming requests must be authenticated and associated with an organization. Client examples use the x-api-key gRPC metadata header. Subscriptions are scoped to trading accounts owned by the authenticated principal’s organization. Subscribe requests must include a valid trading account UUID and at least one event type.

Subscriptions

Once connected, your client can subscribe to message types for a trading account. The subscription messages are defined in protobuf via the proto repository: anthid-labs/proto.

Service Definition

service TradingService {
  rpc StreamEvents(stream StreamEventsRequest)
      returns (stream TradingEvent);

  rpc SubscribeEvents(Subscribe)
      returns (stream TradingEvent);
}

Streaming Models

Anthid supports two streaming patterns.

StreamEvents

A bidirectional gRPC stream intended for backend and native applications. Clients can dynamically subscribe and unsubscribe from trading accounts over an existing connection.

SubscribeEvents

A server-streaming endpoint intended for clients with a fixed subscription. The subscription is established when the request is created and remains active for the lifetime of the stream.

Endpoints

RPC	Request	Response	Use case
`StreamEvents`	Client stream of `StreamEventsRequest` messages	Server stream of `TradingEvent` messages	Dynamic subscribe and unsubscribe over one connection
`SubscribeEvents`	Single `Subscribe` message	Server stream of `TradingEvent` messages	One fixed subscription per stream

Authentication

Streaming requests must include an API key using gRPC metadata.

x-api-key: YOUR_API_KEY

Event Types

Applications can subscribe to one or more event types.

Event Type	Description	Lightspeed	Alpaca
EVENT_TYPE_BROKER_ORDER	Real-time order lifecycle updates	✓	✓
EVENT_TYPE_BROKER_POSITION	Real-time position updates	✓	✗
EVENT_TYPE_BROKER_TRADE	Individual executions against an order	✓	✗

Subscribing to EVENT_TYPE_BROKER_POSITION or EVENT_TYPE_BROKER_TRADE on an Alpaca account is accepted, but no events of that type arrive: the Alpaca integration does not yet report holdings or emit per-execution records. See Alpaca.

Subscription Requests

{
  "trading_account_id": "ACCOUNT_ID",
  "subscriptions": [
    "EVENT_TYPE_BROKER_ORDER",
    "EVENT_TYPE_BROKER_POSITION"
  ]
}

Leave trading_account_id out, or send it empty, to subscribe to every trading account in your organization at once. Each event names the account it belongs to, so one stream can carry the whole organization. The organization is taken from the credentials on the request, never from the request body, so this is still only ever your own accounts.

{
  "subscriptions": [
    "EVENT_TYPE_BROKER_ORDER",
    "EVENT_TYPE_BROKER_POSITION"
  ]
}

Unsubscribe

Unsubscribe is only available on the bidirectional StreamEvents RPC.

{
  "trading_account_id": "ACCOUNT_ID"
}

An empty trading_account_id unsubscribes the organization-wide subscription, matching how it was subscribed. It does not cancel the per-account subscriptions, which are separate and are each unsubscribed by name.

Stream Events

The server may emit the following event types.

Heartbeat

Indicates that the connection remains healthy. The server emits heartbeats approximately every 5 seconds.

Status

Returned when a subscription is added or removed successfully. Successful messages are subscribed and unsubscribed.

Error

Returned when a request cannot be processed.

BrokerOrder

Represents a real-time order lifecycle update. Events may include:

New orders
Accepted orders
Partial fills
Filled orders
Cancelled orders
Rejected orders

BrokerPosition

Represents a real-time position update received from a broker. Position updates are emitted whenever Anthid receives a change in account holdings.

BrokerTrade

Represents one execution against an order. An order can fill in many pieces, so this is the fill-by-fill record that BrokerOrder aggregates into filled_quantity and average_price.

Field	Holds
`account_id`, `organization_id`	Which trading account and organization the execution belongs to
`order_id`	The broker’s own order id
`client_order_id`	The platform order id the execution belongs to
`symbol`, `side`	What traded, and in which direction
`quantity`	Shares in this execution, not the order’s cumulative quantity
`price`	Price of this execution, not the order’s average price
`received_at`	When Anthid observed the execution

Subscribe to this only if you need per-fill detail, such as building a VWAP or reconciling against a broker’s execution report. If you want to know how much of an order has traded, read filled_quantity on BrokerOrder, which already aggregates these.

Internal broker heartbeat events are not forwarded on the public stream.

Connection Lifecycle

Connect to the streaming endpoint.
Authenticate using an API key.
Subscribe to one or more trading accounts.
Receive status confirmation.
Receive real-time events.
Reconnect and resubscribe if the connection is interrupted.

Streams are connection-oriented. If a stream closes, create a new stream and resubscribe to the required trading accounts.

Reconnecting does not replay what was missed. A new stream delivers events from the moment it is established; events that occurred while the connection was down are not redelivered.After any disconnect, reconcile against the ledger’s current endpoints rather than assuming continuity. GET /v1/orders?environment=live and GET /v1/positions?environment=live return the latest known state and are what close the gap. environment is required on both. See Reconciling after a stream disconnect.

Recommended Usage

Use the Streaming API for:

Live order monitoring
Position synchronization
Trading dashboards
Notifications
Automated trading workflows

Use REST APIs for:

Intent submission
Historical queries
Search and filtering
Reporting
Reconciliation workflows

Support

For questions about authentication, request formats, or API behavior, contact support@anthid.com.

Connections

Organizations

Controls

Accounts

Intents

Ledger

Stream

MCP

Availability

Access

Subscriptions

Service Definition

Streaming Models

StreamEvents

SubscribeEvents

Endpoints

Authentication

Event Types

Subscription Requests

Unsubscribe

Stream Events

Heartbeat

Status

Error

BrokerOrder

BrokerPosition

BrokerTrade

Connection Lifecycle

Recommended Usage

Support

​Availability

​Access

​Subscriptions

​Service Definition

​Streaming Models

​StreamEvents

​SubscribeEvents

​Endpoints

​Authentication

​Event Types

​Subscription Requests

​Subscribe

​Unsubscribe

​Stream Events

​Heartbeat

​Status

​Error

​BrokerOrder

​BrokerPosition

​BrokerTrade

​Connection Lifecycle

​Recommended Usage

​Related Resources

​Support

Availability

Access

Subscriptions

Service Definition

Streaming Models

StreamEvents

SubscribeEvents

Endpoints

Authentication

Event Types

Subscription Requests

Subscribe

Unsubscribe

Stream Events

Heartbeat

Status

Error

BrokerOrder

BrokerPosition

BrokerTrade

Connection Lifecycle

Recommended Usage

Related Resources

Support