SQS integration

Receive optional queue messages for order, position, and account status events.

SQS delivery is optional and enabled by request. It is not part of the standard API setup for every firm.

If your firm needs SQS delivery, your onboarding contact will provide the queue details and confirm which events are enabled.

​

Message envelope

Queue messages are JSON objects with a fixed envelope:

{
  "webhook_type": "orders",
  "payload": {
    "event_type": "order",
    "event_id": "evt_queue_test_001",
    "timestamp": "2026-03-16T16:00:00Z",
    "prop_firm_slug": "firm_slug",
    "source": "OMS",
    "account_id": 241
  }
}

Field	Type	Presence	Description
webhook_type	string	Required	Event routing key.
payload	object	Required	Event-specific payload.

​

Event types

webhook_type	payload.event_type	Description
orders	order	New order event.
order-updates	order_update	Order status or fill update.
positions	position_update	Position update. Closed positions are the primary forwarded case.
account-status	account_status	Account status update.

​

Common payload fields

Field	Type	Presence	Description
event_type	string	Required	Event type identifier.
event_id	string	Required	Upstream event identifier.
timestamp	string	Required	ISO-8601 event timestamp.
prop_firm_slug	string	Required	Firm identifier.
source	string	Optional	Upstream source label.
account_id	integer	Required for account events	Ignite account identifier.

​

Payload handling

• Parse the queue message body as JSON.
• Route by webhook_type; use payload.event_type as a secondary check.
• Treat date and time values as strings.
• Treat decimal, price, quantity, and PnL values as strings when present.
• Handle optional and nullable fields defensively.
• Ignore unknown fields for forward compatibility.

​

Position messages

Position events are most useful for closed-position workflows. When positions events are delivered, consumers should expect net_quantity to indicate whether the position is flat.

​

Consumer reliability

• Make processing idempotent using payload.event_id.
• Acknowledge messages only after your processing succeeds.
• Retry transient failures with backoff.
• Dead-letter messages you cannot parse or process after your retry limit.
• Do not assume every API-side update has a matching queue message unless SQS delivery was explicitly enabled for that event.

SQS queue URLs and credentials are provided separately when SQS is enabled for your firm.